Jeg har opdateret mit oprindelige indlæg nedenfor for at afspejle ændringer i de seneste versioner af SQL Source Control (3.0) og SQL Compare (10.1).
Da dette spørgsmål blev stillet for over et år siden, er mit svar måske ikke så nyttigt for dig, men for andre, der måske i øjeblikket vurderer SSC, tænkte jeg, at jeg ville smide mine to cents ind. Vi er lige begyndt at bruge SQL Source Control (SSC) og generelt er jeg ret tilfreds med det indtil videre. Det har dog nogle særheder, især hvis du arbejder i et delt databasemiljø (i modsætning til alle udviklere, der arbejder lokalt) og især arbejder i et ældre miljø, hvor objekter i den samme database er opdelt tilfældigt mellem udviklingsteams.
For at give et kort overblik over, hvordan vi bruger produktet i vores organisation, arbejder vi i et delt miljø, hvor vi alle laver ændringer i den samme udviklingsdatabase, så vi vedhæftede den delte database til kildekontrollageret. Hver udvikler er ansvarlig for at foretage ændringer af objekterne i databasen gennem SQL Server Management Studio (SSMS), og når de er færdige, kan de overføre deres ændringer til kildekontrol. Når vi er klar til at implementere til iscenesættelse, fusionerer build-masteren (mig) udviklingsgrenen af databasekoden til hoved-(staging)-grenen og kører derefter SQL Compare ved at bruge hovedgrenens repository-version af databasen som kilde og live. iscenesættelsesdatabase som målet, og SQL Compare genererer de nødvendige scripts til at implementere ændringerne i iscenesættelsesmiljøet. Iscenesættelse til produktions-implementeringer fungerer på lignende måde. Et andet vigtigt punkt at bemærke er, at i betragtning af at vi deler den samme database med andre udviklingsteams, bruger vi en indbygget funktion i SSC, der giver dig mulighed for at oprette filtre på databaseobjekter efter navn, type osv. Vi manuelt opsætte filtre på vores specifikke teams objekter, undtagen alle andre objekter, så vi ikke ved et uheld foretager andre udviklingsteams ændringer, når vi udfører vores implementeringer.
Så generelt er det et ret simpelt produkt at konfigurere og bruge, og det er rigtig rart, fordi du altid arbejder med levende objekter i SSMS, i modsætning til afbrudte script-filer gemt i et separat kildelager, der risikerer at komme ud af sync. . Det er også rart, fordi SQL Compare genererer implementeringsscripts for dig, så du ikke behøver at bekymre dig om at introducere fejl, som du ville gøre, hvis du oprettede scripts på egen hånd. Og da SQL Compare er et meget modent og stabilt produkt, kan du føle dig ret sikker på, at det vil skabe de rigtige scripts til dig.
Når det er sagt, er her dog nogle af de særheder, som jeg er stødt på indtil videre:
- SSC er ret snakkesalig ud af boksen med hensyn til at kommunikere med db-serveren for at holde styr på databaseelementer, der er ude af synkronisering med kildekontrollageret. Det poller med få millisekunder, og hvis du tilføjer flere udviklere, der alle arbejder mod den samme database ved hjælp af SSC, kan du forestille dig, at vores dba'er ikke var særlig glade. Heldigvis kan du nemt reducere din afstemningsfrekvens til noget mere acceptabelt, dog på bekostning af at ofre lydhøre visuelle meddelelser om, hvornår objekter er blevet ændret.
- Ved brug af objektfiltreringsfunktionen kan du ikke nemt se ud fra at se på objekter i SSMS, hvilke objekter der er inkluderet i dit filter. Så du ved ikke med sikkerhed, om et objekt er under kildekontrol, i modsætning til i Visual Studio, hvor ikoner bruges til at angive kildekontrollerede objekter.
- GUI'et til objektfiltrering er meget klodset. På grund af det faktum, at vi arbejder i et ældre databasemiljø, er der i øjeblikket ikke en klar adskillelse mellem de objekter, som vores team ejer og dem, der ejes af andre teams, så for at forhindre, at vi ved et uheld begår/implementerer andre teams ændringer , har vi oprettet et filtreringsskema for eksplicit at inkludere hvert specifikt objekt, som vi ejer. Som du kan forestille dig, bliver dette ret besværligt, og da GUI'en til at redigere filtrene er sat op til at indtaste et objekt ad gangen, kan det blive ret smertefuldt, især at prøve at sætte dit miljø op for første gang (jeg endte med at at skrive en ansøgning til at gøre dette). Fremover opretter vi et nyt skema til vores applikation for bedre at lette objektfiltrering (udover at det alligevel er en bedre praksis).
- Ved brug af den delte databasemodel har udviklere lov til at foretage eventuelle afventende ændringer til en kildestyret database, selvom ændringerne ikke er deres. SSC giver dig en advarsel, hvis du prøver at tjekke en masse ændringer ind, at disse ændringer måske ikke er dine, men bortset fra at du er på egen hånd. Jeg synes faktisk, at dette er et af SSCs farligste "quirks".
- SQL Compare kan i øjeblikket ikke dele de objektfiltre, der er oprettet af SSC, så du bliver nødt til manuelt at oprette et matchende filter i SQL Compare, så der er fare for, at disse kan blive ude af sync. Jeg endte lige med at klippe og indsætte filtrene fra den underliggende SSC-filterfil ind i SQL Compare-projektfilteret for at undgå at håndtere den klodsede objektfiltrerings-GUI. Jeg tror, at den næste version af SQL Compare vil tillade den at dele filtre med SSC, så i det mindste er dette problem kun et kortvarigt problem. (BEMÆRK:Dette problem er blevet løst i den seneste version af SQL Compare. SQL Compare kan nu bruge de objektfiltre, der er oprettet af SSC.)
- SQL Compare kan heller ikke sammenlignes med et SSC-databaselager, når det startes direkte. Det skal lanceres inde fra SSMS. Jeg tror, at den næste version af SQL Compare vil give denne funktionalitet, så igen er det et andet kortsigtet problem. (BEMÆRK:Dette problem er blevet løst i den seneste version af SQL Compare.)
- Nogle gange er SQL Compare ikke i stand til at oprette de korrekte scripts til at få måldatabasen fra én tilstand til en anden, normalt i det tilfælde, hvor du opdaterer skemaet for eksisterende tabeller, der ikke er tomme, så du i øjeblikket skal skrive manuelle scripts og styre processen selv. Heldigvis vil dette blive løst gennem "migreringsscripts" i den næste udgivelse af SSC, og fra at se på den tidlige udgivelsesversion af produktet, ser det ud til, at implementeringen af denne nye funktion var gennemtænkt og designet. (BEMÆRK:Migration scripts funktionalitet er blevet officielt frigivet. Den understøtter dog ikke forgrening i øjeblikket. Hvis du vil bruge migration scripts, skal du køre sql compare mod din oprindelige udviklingskode gren... den, hvor du tjekkede dine ændringer ind... hvilket er ret klodset og har tvunget mig til at ændre min byggeproces på en mindre ideel måde for at omgå denne begrænsning. Forhåbentlig vil dette blive løst i en fremtidig udgivelse.)
Generelt er jeg ret tilfreds med produktet og med Redgates lydhørhed over for brugerfeedback og den retning, som produktet tager. Produktet er meget nemt at bruge og godt designet, og jeg føler, at i den næste udgivelse eller to vil produktet nok give os det meste, hvis ikke alt, hvad vi har brug for.