Ik heb mijn oorspronkelijke bericht hieronder bijgewerkt om de wijzigingen in de nieuwste versies van SQL Source Control (3.0) en SQL Compare (10.1) weer te geven.
Aangezien deze vraag meer dan een jaar geleden werd gesteld, is mijn antwoord misschien niet zo nuttig voor u, maar voor anderen die momenteel SSC evalueren, dacht ik dat ik mijn twee cent zou toevoegen. We zijn net begonnen met het gebruik van SQL Source Control (SSC) en over het algemeen ben ik er tot nu toe redelijk tevreden mee. Het heeft echter enkele eigenaardigheden, vooral als je in een gedeelde database-omgeving werkt (in tegenstelling tot elke ontwikkelaar die lokaal werkt) en met name werkt in een legacy-omgeving waar objecten in dezelfde database lukraak zijn verdeeld tussen ontwikkelteams.
Om een kort overzicht te geven van hoe we het product in onze organisatie gebruiken, werken we in een gedeelde omgeving waar we allemaal wijzigingen aanbrengen in dezelfde ontwikkelingsdatabase, dus hebben we de gedeelde database toegevoegd aan de bronbeheerrepository. Elke ontwikkelaar is verantwoordelijk voor het aanbrengen van wijzigingen aan de objecten in de database via SQL Server Management Studio (SSMS), en wanneer ze klaar zijn, kunnen ze hun wijzigingen vastleggen in bronbeheer. Wanneer we klaar zijn om te implementeren in staging, voegt de buildmaster (ik) de ontwikkelingstak van de databasecode samen met de hoofdvertakking (staging) en voert vervolgens SQL Compare uit met behulp van de hoofdvertakkingsrepositoryversie van de database als de bron en de live staging-database als het doel en SQL Compare genereert de benodigde scripts om de wijzigingen in de staging-omgeving te implementeren. Staging naar productie-implementaties werkt op dezelfde manier. Een ander belangrijk punt om op te merken is dat, gezien het feit dat we dezelfde database delen met andere ontwikkelingsteams, we een ingebouwde functie van SSC gebruiken waarmee u filters op database-objecten kunt maken op naam, type, enz. We handmatig stel filters in op de objecten van ons specifieke team, met uitsluiting van alle andere objecten, zodat we niet per ongeluk de wijzigingen van andere ontwikkelteams doorvoeren wanneer we onze implementaties uitvoeren.
Dus over het algemeen is het een vrij eenvoudig product om in te stellen en te gebruiken en het is erg leuk omdat je altijd met live objecten in SSMS werkt, in tegenstelling tot losgekoppelde scriptbestanden die zijn opgeslagen in een aparte bronrepository die het risico lopen niet meer synchroon te lopen . Het is ook prettig omdat SQL Compare de implementatiescripts voor u genereert, zodat u zich geen zorgen hoeft te maken over het introduceren van fouten, zoals u zou doen als u de scripts zelf zou maken. En aangezien SQL Compare een zeer volwassen en stabiel product is, kunt u er vrij zeker van zijn dat het de juiste scripts voor u gaat maken.
Dat gezegd hebbende, hier zijn enkele van de eigenaardigheden die ik tot nu toe ben tegengekomen:
- SSC is out-of-the-box behoorlijk spraakzaam in termen van communicatie met de db-server om database-items bij te houden die niet synchroon lopen met de bronbeheerrepository. Het peilt om de paar milliseconden en als je meerdere ontwikkelaars toevoegt die allemaal tegen dezelfde database werken met SSC, kun je je voorstellen dat onze dba's niet erg gelukkig waren. Gelukkig kun je je pollingfrequentie gemakkelijk terugbrengen tot iets acceptabeler, hoewel dit ten koste gaat van responsieve visuele meldingen wanneer objecten zijn gewijzigd.
- Als u de functie voor het filteren van objecten gebruikt, kunt u aan de hand van objecten in SSMS niet gemakkelijk zien welke objecten in uw filter zijn opgenomen. U weet dus niet zeker of een object onder bronbeheer staat, in tegenstelling tot Visual Studio, waar pictogrammen worden gebruikt om brongestuurde objecten aan te duiden.
- De GUI voor het filteren van objecten is erg onhandig. Omdat we in een verouderde databaseomgeving werken, is er momenteel geen duidelijke scheiding tussen de objecten die ons team bezit en die van andere teams, dus om te voorkomen dat we per ongeluk wijzigingen van andere teams doorvoeren/implementeren , hebben we een filterschema opgezet om elk specifiek object dat we bezitten expliciet op te nemen. Zoals je je kunt voorstellen, wordt dit behoorlijk omslachtig, en omdat de GUI om de filters te bewerken is ingesteld om één object tegelijk in te voeren, kan het behoorlijk pijnlijk worden, vooral als je je omgeving voor de eerste keer probeert in te stellen (ik eindigde het schrijven van een aanvraag om dit te doen). In de toekomst maken we een nieuw schema voor onze applicatie om het filteren van objecten beter te vergemakkelijken (hoewel het sowieso een betere gewoonte is).
- Door gebruik te maken van het gedeelde databasemodel, mogen ontwikkelaars alle openstaande wijzigingen doorvoeren in een brongestuurde database, zelfs als de wijzigingen niet van hen zijn. SSC geeft u wel een waarschuwing als u een aantal wijzigingen probeert in te checken dat deze wijzigingen misschien niet van u zijn, maar dat u er verder alleen voor staat. Ik vind dit eigenlijk een van SSC's gevaarlijkste "eigenaardigheden".
- SQL Compare kan momenteel de objectfilters die door SSC zijn gemaakt niet delen, dus u zou handmatig een overeenkomend filter moeten maken in SQL Compare, dus het gevaar bestaat dat deze niet meer synchroon lopen. Ik heb zojuist de filters uit het onderliggende SSC-filterbestand geknipt en geplakt in het SQL Compare-projectfilter om te voorkomen dat ik te maken krijg met de onhandige GUI voor het filteren van objecten. Ik geloof dat de volgende versie van SQL Compare het mogelijk zal maken om filters te delen met SSC, dus dit probleem is in ieder geval slechts van korte duur. (OPMERKING:dit probleem is opgelost in de nieuwste versie van SQL Compare. SQL Compare kan nu de objectfilters gebruiken die door SSC zijn gemaakt.)
- SQL Compare kan ook niet worden vergeleken met een SSC-databaserepository wanneer deze rechtstreeks wordt gestart. Het moet worden gestart vanuit SSMS. Ik geloof dat de volgende versie van SQL Compare deze functionaliteit zal bieden, dus nogmaals, het is een ander probleem op korte termijn. (OPMERKING:dit probleem is opgelost in de nieuwste versie van SQL Compare.)
- Soms is SQL Compare niet in staat om de juiste scripts te maken om de doeldatabase van de ene staat naar de andere te krijgen, meestal in het geval dat u het schema van bestaande tabellen bijwerkt die niet leeg zijn, dus u moet momenteel schrijf handmatige scripts en beheer het proces zelf. Gelukkig zal dit worden aangepakt door middel van "migratiescripts" in de volgende release van SSC, en uit de vroege releaseversie van het product blijkt dat de implementatie van deze nieuwe functie goed doordacht en ontworpen was. (OPMERKING:de functionaliteit voor migratiescripts is officieel vrijgegeven. Het ondersteunt momenteel echter geen vertakking. Als u migratiescripts wilt gebruiken, moet u sql-vergelijking uitvoeren met uw oorspronkelijke ontwikkelingscodevertakking... je hebt je wijzigingen ingecheckt... wat behoorlijk onhandig is en me heeft gedwongen mijn bouwproces op een minder dan ideale manier aan te passen om deze beperking te omzeilen. Hopelijk wordt dit in een toekomstige release aangepakt.)
Over het algemeen ben ik best tevreden met het product en met Redgate's reactievermogen op gebruikersfeedback en de richting die het product inslaat. Het product is zeer gebruiksvriendelijk en goed ontworpen, en ik denk dat het product ons in de volgende twee releases waarschijnlijk het meeste, zo niet alles, zal geven van wat we nodig hebben.