Jag har uppdaterat mitt ursprungliga inlägg nedan för att återspegla ändringar i de senaste versionerna av SQL Source Control (3.0) och SQL Compare (10.1).
Eftersom den här frågan ställdes för över ett år sedan kanske mitt svar inte är så användbart för dig, men för andra som för närvarande utvärderar SSC tänkte jag slänga in mina två cent. Vi har precis börjat använda SQL Source Control (SSC) och överlag är jag ganska nöjd med det så här långt. Det har dock vissa egenheter, särskilt om du arbetar i en delad databasmiljö (i motsats till att alla utvecklare arbetar lokalt) och särskilt arbetar i en äldre miljö där objekt i samma databas är uppdelade på måfå mellan utvecklingsteam.
För att ge en kort översikt över hur vi använder produkten i vår organisation arbetar vi i en delad miljö där vi alla gör ändringar i samma utvecklingsdatabas, så vi kopplade den delade databasen till källkontrollförrådet. Varje utvecklare ansvarar för att göra ändringar i objekten i databasen genom SQL Server Management Studio (SSMS), och när de är klara kan de göra ändringar i källkontroll. När vi är redo att distribuera till iscensättning slår byggmästaren (mig) samman utvecklingsgrenen av databaskoden till huvudgrenen (staging) och kör sedan SQL Compare med hjälp av huvudgrenens arkivversion av databasen som källa och live iscensättningsdatabasen som mål, och SQL Compare genererar de nödvändiga skripten för att distribuera ändringarna som gjorts i iscensättningsmiljön. Implementering av iscensättning till produktion fungerar på liknande sätt. En annan viktig punkt att notera är att, med tanke på att vi delar samma databas med andra utvecklingsteam, använder vi en inbyggd funktion i SSC som låter dig skapa filter på databasobjekt efter namn, typ, etc. Vi manuellt ställ in filter på vårt specifika teams objekt, exklusive alla andra objekt, så att vi inte av misstag begår andra utvecklingsteams ändringar när vi gör våra distributioner.
Så generellt sett är det en ganska enkel produkt att ställa in och använda och det är riktigt trevligt eftersom du alltid arbetar med levande objekt i SSMS, till skillnad från frånkopplade skriptfiler lagrade i ett separat källlager som riskerar att hamna ur synk . Det är också trevligt eftersom SQL Compare genererar distributionsskripten åt dig så att du inte behöver oroa dig för att introducera fel som du skulle göra om du skapade skripten på egen hand. Och eftersom SQL Compare är en mycket mogen och stabil produkt, kan du känna dig ganska säker på att den kommer att skapa de rätta skripten åt dig.
Med det sagt, men här är några av egenheter som jag har stött på hittills:
- SSC är ganska pratsam direkt när det gäller att kommunicera med db-servern för att hålla reda på databasobjekt som inte är synkroniserade med källkontrollförrådet. Den undersökningar med några millisekunder och om du lägger till flera utvecklare som alla arbetar mot samma databas med hjälp av SSC, kan du föreställa dig att våra dba:er inte var särskilt nöjda. Lyckligtvis kan du enkelt minska din omröstningsfrekvens till något mer acceptabelt, men till priset av att du offra responsiva visuella meddelanden om när objekt har ändrats.
- Med hjälp av objektfiltreringsfunktionen kan du inte enkelt avgöra från att titta på objekt i SSMS vilka objekt som ingår i ditt filter. Så du vet inte säkert om ett objekt är under källkontroll, till skillnad från i Visual Studio, där ikoner används för att indikera källkontrollerade objekt.
- Objektfiltreringsgränssnittet är väldigt klumpigt. På grund av det faktum att vi arbetar i en äldre databasmiljö finns det för närvarande ingen tydlig åtskillnad mellan de objekt som vårt team äger och de som ägs av andra team, så för att förhindra att vi av misstag genomför/distribuerar andra teams ändringar , har vi satt upp ett filtreringsschema för att explicit inkludera varje specifikt objekt som vi äger. Som du kan föreställa dig blir detta ganska besvärligt, och eftersom det grafiska användargränssnittet för att redigera filtren är inställt för att gå in i ett objekt i taget, kan det bli ganska smärtsamt, speciellt att försöka ställa in din miljö för första gången (det slutade med att jag skriva en ansökan för att göra detta). Framöver skapar vi ett nytt schema för vår applikation för att bättre underlätta objektfiltrering (förutom att det ändå är en bättre praxis).
- Med den delade databasmodellen tillåts utvecklare att genomföra alla väntande ändringar i en källkontrollerad databas, även om ändringarna inte är deras. SSC ger dig en varning om du försöker checka in en massa ändringar att dessa ändringar kanske inte är dina, men förutom att du är på egen hand. Jag tycker faktiskt att detta är en av SSC:s farligaste "egenheter".
- SQL Compare kan för närvarande inte dela objektfiltren som skapats av SSC, så du måste manuellt skapa ett matchande filter i SQL Compare, så det finns en risk att dessa kan hamna ur synk. Det slutade precis med att jag klippte ut och klistrade filtren från den underliggande SSC-filterfilen i SQL Compare-projektfiltret för att undvika att hantera det klumpiga objektfiltreringsgränssnittet. Jag tror att nästa version av SQL Compare kommer att tillåta den att dela filter med SSC, så det här problemet är åtminstone ett kortvarigt problem. (OBS:Det här problemet har lösts i den senaste versionen av SQL Compare. SQL Compare kan nu använda objektfiltren som skapats av SSC.)
- SQL Compare kan inte heller jämföras med ett SSC-databaslager när det startas direkt. Det måste startas inifrån SSMS. Jag tror att nästa version av SQL Compare kommer att tillhandahålla denna funktionalitet, så återigen är det ett annat kortsiktigt problem. (OBS:Det här problemet har lösts i den senaste versionen av SQL Compare.)
- Ibland kan SQL Compare inte skapa de rätta skripten för att få måldatabasen från ett tillstånd till ett annat, vanligtvis i det fall du uppdaterar schemat för befintliga tabeller som inte är tomma, så du måste för närvarande skriva manuella skript och hantera processen själv. Lyckligtvis kommer detta att åtgärdas genom "migreringsskript" i nästa utgåva av SSC, och från att titta på den tidiga versionen av produkten verkar det som att implementeringen av denna nya funktion var genomtänkt och designad. (OBS:Migreringsskriptfunktionaliteten har officiellt släppts. Men den stöder för närvarande inte förgrening. Om du vill använda migreringsskript måste du köra sql compare mot din ursprungliga utvecklingskodgren... den där du checkade in dina ändringar... vilket är ganska klumpigt och har tvingat mig att ändra min byggprocess på ett mindre än idealiskt sätt för att komma runt denna begränsning. Förhoppningsvis kommer detta att åtgärdas i en framtida version.)
Sammantaget är jag ganska nöjd med produkten och med Redgates lyhördhet för användarfeedback och riktningen som produkten tar. Produkten är väldigt lätt att använda och väldesignad, och jag känner att i nästa version eller två kommer produkten förmodligen att ge oss det mesta, om inte allt, av det vi behöver.