Ho aggiornato il mio post originale di seguito per riflettere le modifiche nelle ultime versioni di SQL Source Control (3.0) e SQL Compare (10.1).
Dal momento che questa domanda è stata posta più di un anno fa, la mia risposta potrebbe non essere di grande aiuto per te, ma per altri che potrebbero attualmente valutare SSC, ho pensato di aggiungere i miei due centesimi. Abbiamo appena iniziato a utilizzare SQL Source Control (SSC) e nel complesso ne sono abbastanza soddisfatto finora. Tuttavia, presenta alcune stranezze, soprattutto se si lavora in un ambiente di database condiviso (al contrario di ogni sviluppatore che lavora localmente) e in particolare si lavora in un ambiente legacy in cui gli oggetti nello stesso database sono divisi a casaccio tra i team di sviluppo.
Per fornire una breve panoramica di come stiamo utilizzando il prodotto nella nostra organizzazione, stiamo lavorando in un ambiente condiviso in cui tutti apportiamo modifiche allo stesso database di sviluppo, quindi abbiamo collegato il database condiviso al repository di controllo del codice sorgente. Ogni sviluppatore è responsabile delle modifiche agli oggetti nel database tramite SQL Server Management Studio (SSMS) e, al termine, può eseguire il commit delle modifiche nel controllo del codice sorgente. Quando siamo pronti per l'implementazione nello staging, il build master (me) unisce il ramo di sviluppo del codice del database al ramo principale (staging) e quindi esegue SQL Compare utilizzando la versione del repository del ramo principale del database come sorgente e live database di staging come destinazione e SQL Compare genera gli script necessari per distribuire le modifiche apportate all'ambiente di staging. Lo staging per le distribuzioni di produzione funziona in modo simile. Un altro punto importante da notare è che, dato che condividiamo lo stesso database con altri team di sviluppo, utilizziamo una funzionalità integrata di SSC che consente di creare filtri sugli oggetti del database per nome, tipo, ecc. imposta filtri sugli oggetti del nostro team specifico, escludendo tutti gli altri oggetti, in modo da non commettere accidentalmente le modifiche di altri team di sviluppo quando eseguiamo le nostre distribuzioni.
Quindi in generale è un prodotto abbastanza semplice da configurare e utilizzare ed è davvero bello perché lavori sempre con oggetti live in SSMS, al contrario di file di script disconnessi archiviati in un repository di origine separato che corre il rischio di perdere la sincronizzazione . È anche utile perché SQL Compare genera gli script di distribuzione per te, quindi non devi preoccuparti di introdurre errori come faresti se stessi creando gli script da solo. E poiché SQL Compare è un prodotto molto maturo e stabile, puoi essere abbastanza sicuro che creerà gli script appropriati per te.
Detto questo, tuttavia, ecco alcune delle stranezze in cui mi sono imbattuto finora:
- SSC è piuttosto loquace in termini di comunicazione con il server db per tenere traccia degli elementi del database che non sono sincronizzati con il repository del controllo del codice sorgente. Esegue il polling ogni pochi millisecondi e se aggiungi più sviluppatori che lavorano tutti sullo stesso database utilizzando SSC, puoi immaginare che i nostri dba non fossero molto contenti. Fortunatamente, puoi facilmente ridurre la tua frequenza di polling a qualcosa di più accettabile, anche se a costo di sacrificare notifiche visive reattive di quando gli oggetti sono stati modificati.
- Utilizzando la funzione di filtraggio degli oggetti, non puoi facilmente distinguere osservando gli oggetti in SSMS quali oggetti sono inclusi nel tuo filtro. Quindi non sai con certezza se un oggetto è sotto il controllo del codice sorgente, a differenza di Visual Studio, dove le icone vengono utilizzate per indicare gli oggetti controllati dal codice sorgente.
- La GUI di filtraggio degli oggetti è molto goffa. A causa del fatto che stiamo lavorando in un ambiente di database legacy, al momento non esiste una chiara separazione tra gli oggetti di proprietà del nostro team e quelli di proprietà di altri team, quindi per impedirci di eseguire/distribuire accidentalmente le modifiche di altri team , abbiamo impostato uno schema di filtraggio per includere esplicitamente ogni oggetto specifico di nostra proprietà. Come puoi immaginare, questo diventa piuttosto ingombrante, e poiché la GUI per modificare i filtri è impostata per inserire un oggetto alla volta, potrebbe diventare piuttosto doloroso, soprattutto provando a configurare il tuo ambiente per la prima volta (ho finito per scrivere un'applicazione per farlo). Andando avanti, stiamo creando un nuovo schema per la nostra applicazione per facilitare meglio il filtraggio degli oggetti (oltre ad essere comunque una pratica migliore).
- Utilizzando il modello di database condiviso, gli sviluppatori possono eseguire il commit di eventuali modifiche in sospeso in un database controllato dal codice sorgente, anche se le modifiche non sono loro. SSC ti avvisa se provi a controllare una serie di modifiche che queste modifiche potrebbero non essere tue, ma a parte questo sei da solo. In realtà trovo che questa sia una delle "stranezze" più pericolose di SSC.
- SQL Compare attualmente non può condividere i filtri degli oggetti creati da SSC, quindi dovresti creare manualmente un filtro corrispondente in SQL Compare, quindi c'è il pericolo che questi possano perdere la sincronizzazione. Ho appena finito per tagliare e incollare i filtri dal file del filtro SSC sottostante nel filtro del progetto SQL Compare per evitare di gestire la GUI di filtraggio degli oggetti goffa. Credo che la prossima versione di SQL Compare consentirà di condividere filtri con SSC, quindi almeno questo problema è solo a breve termine. (NOTA:questo problema è stato risolto nell'ultima versione di SQL Compare. SQL Compare ora può utilizzare i filtri oggetto creati da SSC.)
- Anche SQL Compare non può confrontare con un repository di database SSC quando viene avviato direttamente. Deve essere lanciato da SSMS. Credo che la prossima versione di SQL Compare fornirà questa funzionalità, quindi ancora una volta è un altro problema a breve termine. (NOTA:questo problema è stato risolto nell'ultima versione di SQL Compare.)
- A volte SQL Compare non è in grado di creare gli script appropriati per portare il database di destinazione da uno stato all'altro, di solito nel caso in cui stai aggiornando lo schema di tabelle esistenti che non sono vuote, quindi al momento devi scrivere script manuali e gestire il processo da soli. Fortunatamente, questo problema verrà affrontato tramite "script di migrazione" nella prossima versione di SSC e, osservando la versione iniziale del prodotto, sembra che l'implementazione di questa nuova funzionalità sia stata ben congegnata e progettata. (NOTA:la funzionalità degli script di migrazione è stata ufficialmente rilasciata. Tuttavia, attualmente non supporta la ramificazione. Se desideri utilizzare gli script di migrazione, dovrai eseguire sql compare con il tuo ramo di codice di sviluppo originale... quello in cui hai controllato le tue modifiche... il che è piuttosto goffo e mi ha costretto a modificare il mio processo di compilazione in un modo tutt'altro che ideale per aggirare questa limitazione. Si spera che questo venga risolto in una versione futura.)
Nel complesso, sono abbastanza soddisfatto del prodotto e della reattività di Redgate al feedback degli utenti e della direzione che sta prendendo il prodotto. Il prodotto è molto facile da usare e ben progettato e ritengo che nelle prossime versioni o due il prodotto probabilmente ci darà la maggior parte, se non tutto, di ciò di cui abbiamo bisogno.
