Я обновил свой исходный пост ниже, чтобы отразить изменения в последних версиях SQL Source Control (3.0) и SQL Compare (10.1).
Поскольку этот вопрос был задан более года назад, мой ответ может быть не очень полезен для вас, но для тех, кто в настоящее время оценивает SSC, я решил добавить свои пять копеек. Мы только начали использовать SQL Source Control (SSC), и в целом я пока им вполне доволен. Однако у него есть некоторые особенности, особенно если вы работаете в среде с общей базой данных (в отличие от каждого разработчика, работающего локально) и особенно в устаревшей среде, где объекты в одной базе данных случайным образом распределяются между группами разработчиков.
Чтобы дать краткий обзор того, как мы используем продукт в нашей организации, мы работаем в общей среде, где все мы вносим изменения в одну и ту же базу данных разработки, поэтому мы присоединили общую базу данных к репозиторию системы управления версиями. Каждый разработчик несет ответственность за внесение изменений в объекты в базе данных с помощью SQL Server Management Studio (SSMS), и когда они будут завершены, они могут зафиксировать свои изменения в системе управления версиями. Когда мы готовы к промежуточному развертыванию, мастер сборки (я) объединяет разрабатываемую ветку кода базы данных с основной (промежуточной) веткой, а затем запускает SQL Compare, используя версию репозитория основной ветки базы данных в качестве источника и живую. промежуточную базу данных в качестве целевой, а SQL Compare сгенерирует необходимые сценарии для развертывания изменений, внесенных в промежуточную среду. Промежуточное развертывание в рабочей среде работает аналогичным образом. Еще один важный момент, который следует отметить, заключается в том, что, учитывая тот факт, что мы совместно используем одну и ту же базу данных с другими группами разработчиков, мы используем встроенную функцию SSC, которая позволяет создавать фильтры для объектов базы данных по имени, типу и т. д. Мы вручную настроить фильтры для объектов нашей конкретной группы, исключая все другие объекты, чтобы мы случайно не зафиксировали изменения другой группы разработчиков при выполнении наших развертываний.
Так что в целом это довольно простой продукт в настройке и использовании, и это действительно приятно, потому что вы всегда работаете с живыми объектами в SSMS, а не с отключенными файлами сценариев, хранящимися в отдельном исходном репозитории, которые рискуют рассинхронизироваться. . Это также хорошо, потому что SQL Compare создает сценарии развертывания для вас, поэтому вам не нужно беспокоиться о внесении ошибок, как если бы вы создавали сценарии самостоятельно. А поскольку SQL Compare — очень зрелый и стабильный продукт, вы можете быть уверены, что он создаст для вас нужные сценарии.
С учетом сказанного, однако, вот некоторые из причуд, с которыми я столкнулся до сих пор:
- SSC довольно болтлив из коробки с точки зрения связи с сервером базы данных, чтобы отслеживать элементы базы данных, которые не синхронизированы с репозиторием системы управления версиями. Он опрашивает каждые несколько миллисекунд, и если вы добавите несколько разработчиков, работающих с одной и той же базой данных с помощью SSC, вы можете себе представить, что наши администраторы баз данных были не очень довольны. К счастью, вы можете легко уменьшить частоту опроса до чего-то более приемлемого, хотя и за счет потери отзывчивых визуальных уведомлений об изменении объектов.
- Используя функцию фильтрации объектов, вы не можете легко определить, глядя на объекты в SSMS, какие объекты включены в ваш фильтр. Таким образом, вы не знаете наверняка, находится ли объект под контролем источника, в отличие от Visual Studio, где значки используются для обозначения объектов, контролируемых источником.
- Графический интерфейс фильтрации объектов очень неуклюж. Из-за того, что мы работаем в устаревшей среде базы данных, в настоящее время нет четкого разделения между объектами, которыми владеет наша команда, и объектами, принадлежащими другим командам, поэтому для предотвращения случайного внесения/развертывания изменений других команд , мы настроили схему фильтрации, чтобы явно включать каждый конкретный объект, которым мы владеем. Как вы можете себе представить, это становится довольно громоздким, а поскольку графический интерфейс для редактирования фильтров настроен на ввод одного объекта за раз, это может стать довольно болезненным, особенно при попытке настроить вашу среду в первый раз (в итоге я написать заявление об этом). В будущем мы создадим новую схему для нашего приложения, чтобы упростить фильтрацию объектов (помимо того, что это в любом случае лучшая практика).
- Используя модель общей базы данных, разработчикам разрешено фиксировать любые ожидающие изменения в базе данных, контролируемой источником, даже если эти изменения не принадлежат им. 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 на отзывы пользователей и направлением, в котором развивается продукт. Продукт очень прост в использовании и хорошо разработан, и я чувствую, что в следующих версиях продукт, вероятно, даст нам большую часть, если не все, что нам нужно.
person
Mary Hamlin
schedule
27.10.2011