Я обновил свой исходный пост ниже, чтобы отразить изменения в последних версиях SQL Source Control (3.0) и SQL Compare (10.1).
Поскольку этот вопрос был задан более года назад, мой ответ может быть не таким уж полезным для вас, но для тех, кто в настоящее время может оценивать SSC, я подумал, что добавлю свои два цента. Мы только начали использовать SQL Source Control (SSC), и в целом я до сих пор доволен им. Однако у него есть свои особенности, особенно если вы работаете в среде общих баз данных (в отличие от каждого разработчика, работающего локально) и особенно работаете в устаревшей среде, где объекты в одной и той же базе данных случайно разделены между группами разработчиков.
Чтобы дать краткий обзор того, как мы используем продукт в нашей организации, мы работаем в общей среде, в которой мы все вносим изменения в одну и ту же базу данных разработки, поэтому мы подключили общую базу данных к репозиторию контроля версий. Каждый разработчик несет ответственность за внесение изменений в объекты в базе данных через SQL Server Management Studio (SSMS), и после их завершения они могут передать свои изменения в систему контроля версий. Когда мы будем готовы к развертыванию, мастер сборки (me) объединяет ветвь разработки кода базы данных с основной (промежуточной) ветвью, а затем запускает SQL Compare, используя версию базы данных основного ветки репозитория в качестве источника и оперативную версию. промежуточная база данных в качестве цели, и SQL Compare генерирует необходимые сценарии для развертывания изменений, внесенных в промежуточную среду. Подготовка к внедрению в производство работает аналогичным образом. Еще один важный момент, который следует отметить, заключается в том, что, учитывая тот факт, что мы совместно используем одну и ту же базу данных с другими группами разработчиков, мы используем встроенную функцию SSC, которая позволяет создавать фильтры для объектов базы данных по имени, типу и т. Д. Мы вручную установите фильтры для объектов нашей конкретной команды, исключая все другие объекты, чтобы мы не могли случайно зафиксировать изменения, сделанные другими разработчиками при выполнении наших развертываний.
Так что в целом это довольно простой продукт для настройки и использования, и он действительно хорош, потому что вы всегда работаете с живыми объектами в SSMS, в отличие от отключенных файлов сценариев, хранящихся в отдельном исходном репозитории, которые рискуют получить не синхронизировано. Это также хорошо, потому что SQL Compare генерирует сценарии развертывания для вас, поэтому вам не нужно беспокоиться о появлении ошибок, как если бы вы создавали сценарии самостоятельно. А так как SQL Compare является очень зрелым и стабильным продуктом, вы можете быть уверены, что он создаст для вас подходящие сценарии.
С учетом сказанного, однако, вот некоторые из причуд, с которыми я столкнулся до сих пор:
- SSC довольно болтлив из коробки с точки зрения связи с сервером БД, чтобы отслеживать элементы базы данных, которые не синхронизированы с репозиторием контроля версий. Он опрашивает каждые несколько миллисекунд, и если вы добавите нескольких разработчиков, работающих с одной и той же базой данных с использованием SSC, вы можете представить, что наши dba не очень-то довольны. К счастью, вы можете легко уменьшить частоту опроса до чего-то более приемлемого, хотя и ценой того, чтобы жертвовать визуальными уведомлениями о том, когда объекты были изменены.
- Используя функцию фильтрации объектов, вы не можете легко определить, глядя на объекты в SSMS, какие объекты включены в ваш фильтр. Таким образом, вы не знаете наверняка, находится ли объект под контролем источника, в отличие от Visual Studio, где значки используются для обозначения объектов, контролируемых источником.
- GUI фильтрации объектов очень неуклюжий.В связи с тем, что мы работаем в устаревшей среде баз данных, в настоящее время нет четкого разделения между объектами, которыми владеет наша команда, и объектами, принадлежащими другим командам, поэтому мы не можем случайно зафиксировать / внедрить изменения других команд.мы настроили схему фильтрации, чтобы явно включать каждый конкретный объект, которым мы владеем.Как вы можете себе представить, это становится довольно громоздким, и поскольку графический интерфейс для редактирования фильтров настроен так, чтобы вводить по одному объекту за раз, это может стать довольно болезненным, особенно при попытке настроить вашу среду в первый раз (я закончилнаписание приложения для этого).В дальнейшем мы создаем новую схему для нашего приложения, чтобы лучше упростить фильтрацию объектов (помимо того, что в любом случае это лучше).
- Используя модель общей базы данных, разработчикам разрешено вносить любые ожидающие изменения в контролируемый источникбазы данных, даже если изменения не их.SSC предупреждает вас, если вы попытаетесь зафиксировать кучу изменений, что эти изменения могут быть не вашими, а другими, которые вы делаете самостоятельно.Я считаю, что это одна из самых опасных «причуд» SSC.
- SQL Compare в настоящее время не может совместно использовать фильтры объектов, созданные в SSC, поэтому вам придется вручную создать соответствующий фильтр в SQL Compare, поэтому существует опасность, что они могут выйти из-под контроля.Я только что закончил вырезать и вставить фильтры из базового файла фильтра SSC в фильтр проекта SQL Compare, чтобы избежать работы с неуклюжим графическим интерфейсом фильтрации объектов.Я полагаю, что следующая версия SQL Compare позволит ему совместно использовать фильтры с SSC, поэтому, по крайней мере, эта проблема является только краткосрочной. (ПРИМЕЧАНИЕ. Эта проблема была решена в последней версии SQL Compare. В SQL Compare теперь можно использовать фильтры объектов, созданные SSC.)
- SQL Compare также нельзя сравнивать сРепозиторий базы данных SSC при запуске напрямую.Он должен быть запущен изнутри SSMS.Я полагаю, что следующая версия SQL Compare обеспечит эту функциональность, поэтому, опять же, это еще одна краткосрочная проблема. (ПРИМЕЧАНИЕ. Эта проблема была решена в последней версии SQL Compare.)
- Иногда SQL Compare не может создать надлежащие сценарии для перевода целевой базы данных из одного состояния вдругой, обычно в случае, когда вы обновляете схемы существующих таблиц, которые не являются пустыми, поэтому вам в настоящее время приходится писать сценарии вручную и самостоятельно управлять процессом.К счастью, это будет решено с помощью «сценариев миграции» в следующем выпуске SSC, и, глядя на более раннюю версию продукта, кажется, что реализация этой новой функции была хорошо продумана и разработана. (ПРИМЕЧАНИЕ. Функциональность скриптов миграции официально выпущена. Однако в настоящее время она не поддерживает ветвление. Если вы хотите использовать скрипты миграции, вам нужно будет выполнить сравнение sql с исходной веткой кода разработки ... той, гдеВы проверили свои изменения ... что довольно неуклюже и заставило меня изменить мой процесс сборки не в идеале, чтобы обойти это ограничение. Надеюсь, это будет исправлено в следующем выпуске.)
В целом, я очень доволен продуктом и отзывчивостью Redgate к отзывам пользователей и направлению, в котором идет продукт.Продукт очень прост в использовании и хорошо спроектирован, и я чувствую, что в следующем выпуске или двух продукт, вероятно, даст нам большинство, если не все, того, что нам нужно.