Актуализирах оригиналната си публикация по-долу, за да отразя промените в най-новите версии на 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 е доста разговорлив по отношение на комуникацията с db сървъра, за да следи елементи от базата данни, които не са синхронизирани с хранилището за контрол на източника. Проучва на всеки няколко милисекунди и ако добавите множество разработчици, всички работещи срещу една и съща база данни, използвайки SSC, можете да си представите, че нашите dba не са много доволни. За щастие можете лесно да намалите честотата си на запитване до нещо по-приемливо, макар и с цената на жертване на реагиращи визуални известия за това, когато обектите са били променени.
- Използвайки функцията за филтриране на обекти, не можете лесно да разберете, като гледате обекти в SSMS кои обекти са включени във вашия филтър. Така че не знаете със сигурност дали даден обект е под контрол на източника, за разлика от Visual Studio, където иконите се използват за обозначаване на обекти, контролирани от източника.
- ГПИ за филтриране на обекти е много тромав. Поради факта, че работим в среда на наследена база данни, в момента няма ясно разделение между обектите, които нашият екип притежава, и тези, които са собственост на други екипи, така че за да ни попречи на случайно извършване/разгръщане на промени на други екипи , създадохме схема за филтриране, за да включим изрично всеки конкретен обект, който притежаваме. Както можете да си представите, това става доста тромаво и тъй като GUI за редактиране на филтрите е настроен да въвежда един обект наведнъж, може да стане доста болезнено, особено опитвайки се да настроите вашата среда за първи път (в крайна сметка писане на приложение за това). Занапред създаваме нова схема за нашето приложение, за да улесним по-добре филтрирането на обекти (освен че така или иначе е по-добра практика).
- Използвайки модела на споделена база данни, на разработчиците е разрешено да извършват всички предстоящи промени в база данни с контролиран източник, дори ако промените не са техни. SSC ви предупреждава, ако се опитате да проверите куп промени, че тези промени може да не са ваши, но освен че сте сами. Всъщност намирам това за една от най-опасните „странности“ на SSC.
- SQL Compare в момента не може да споделя обектните филтри, създадени от SSC, така че ще трябва ръчно да създадете съответстващ филтър в SQL Compare, така че има опасност те да се разпаднат в синхрон. Току-що завърших с изрязване и поставяне на филтрите от основния SSC филтърен файл във филтъра на проекта SQL Compare, за да избегна работа с тромавия GUI за филтриране на обекти. Вярвам, че следващата версия на SQL Compare ще му позволи да споделя филтри със SSC, така че поне този проблем е само краткосрочен. (ЗАБЕЛЕЖКА:Този проблем е решен в най-новата версия на SQL Compare. SQL Compare вече може да използва обектните филтри, създадени от SSC.)
- SQL Compare също не може да сравнява с хранилище на SSC база данни, когато се стартира директно. Трябва да се стартира от SSMS. Вярвам, че следващата версия на SQL Compare ще предостави тази функционалност, така че отново това е друг краткосрочен проблем. (ЗАБЕЛЕЖКА:Този проблем е решен в най-новата версия на SQL Compare.)
- Понякога SQL Compare не може да създаде правилните скриптове, за да прехвърли целевата база данни от едно състояние в друго, обикновено в случай, че актуализирате схемата на съществуващи таблици, които не са празни, така че в момента трябва да пишете ръчни скриптове и сами управлявайте процеса. За щастие, това ще бъде адресирано чрез „скриптове за миграция“ в следващото издание на SSC и от разглеждането на ранната версия на продукта изглежда, че внедряването на тази нова функция е добре обмислено и проектирано. (ЗАБЕЛЕЖКА:Функционалността на скриптовете за миграция е официално пусната. Понастоящем обаче не поддържа разклоняване. Ако искате да използвате скриптове за миграция, ще трябва да изпълните sql сравнение с вашия оригинален клон на кода за разработка... този, където проверихте промените си... което е доста тромаво и ме принуди да модифицирам моя процес на изграждане по не толкова идеален начин, за да заобиколя това ограничение. Надяваме се, че това ще бъде разгледано в бъдеща версия.)
Като цяло съм доста доволен от продукта и от отзивчивостта на Redgate към отзивите на потребителите и посоката, която поема продуктът. Продуктът е много лесен за използване и добре проектиран и смятам, че в следващите две версии продуктът вероятно ще ни даде повечето, ако не и всичко, от това, от което се нуждаем.
