Любой, кто использует SQL Source Control из Red Gate

я обновил свой исходный пост ниже, чтобы отразить изменения в последних версиях SQL Source Control (3.0) и SQL Compare (10.1).

Так как этот вопрос был задан более года назад, мой ответ может быть не так полезен для вас, но для других, кто в настоящее время может оценивать SSC, я думал, что брошу свои два цента. Мы только начали использовать SQL Source Control (SSC), и в целом я довольно доволен этим до сих пор. Хотя есть некоторые причуды , особенно, если вы работаете в среде общей базы данных (в отличие от каждого разработчика, работающего локально) и особенно в устаревшей среде, где объекты в той же базе данных разделены случайным образом между командами разработчиков.

чтобы дать краткий обзор того, как мы используем продукт в нашей организации, мы работаем в общей среде, где все мы вносим изменения в одну и ту же базу данных разработки, поэтому мы прикрепили общую базу данных к системе управления версиями хранилище. Каждый разработчик несет ответственность за внесение изменений в объекты базы данных с помощью среды SQL Server Management Studio (SSMS), а по завершении их можно зафиксировать в системе управления версиями. Когда мы готовы к развертыванию на промежуточной стадии, мастер сборки (me) объединяет ветвь разработки кода базы данных с основной (промежуточной) ветвью, а затем запускает SQL Compare, используя версию репозитория основной ветви базы данных в качестве источника и живую промежуточную базу данных в качестве target и 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 Сравнивать.)
• иногда SQL Compare не может создать правильные скрипты, чтобы получить целевую базу данных из одного состояния в другое, обычно в случае, когда вы обновляете схему существующих таблиц, которые не пусты, поэтому в настоящее время вам нужно писать ручные скрипты и управлять процессом самостоятельно. К счастью, это будет устранено с помощью "сценариев миграции" в следующем выпуске SSC, и, глядя на раннюю версию продукта, кажется, что реализация этой новой функции была хорошо продумана и разработана. (Примечание: функциональность сценариев миграции официально выпущена. Однако в настоящее время он не поддерживает ветвление. Если вы хотите использовать сценарии миграции, вам нужно будет запустить sql compare против вашей исходной ветви кода разработки... где вы проверили свои изменения... что довольно неуклюже и заставило меня изменить процесс сборки менее идеальным способом, чтобы обойти это ограничение. Надеюсь, это будет рассмотрено в будущем выпуске.)

в целом, я очень доволен продуктом и реактивностью Redgate на отзывы пользователей и направление, в котором продукт принимает. Продукт очень прост в использовании и хорошо разработан, и я чувствую, что в следующем выпуске или двух продукт, вероятно, даст нам большую часть, если не все, что нам нужно.

мы провели обширную оценку продукта Red Gate и обнаружили несколько основных недостатков. Если вы хотите посмотреть, кто изменил объект, вы не можете сделать это без привилегии системного администратора. Продукт должен посмотреть трассировку на вашем сервере, которая требует этих прав. Я в команде 5 + человек, и не зная, кто ожидал изменений, это то, что остановит нас от использования продукта.