Chiunque con controllo del codice sorgente SQL da Red Gate

Question

Ci sono state cercando delle possibili soluzioni per il nostro controllo SQL Source. Ho appena incontrato il controllo Red Gates sorgente SQL e mi chiedevo se qualcuno ha attuato? Ho intenzione di scaricare il processo e dare un colpo, ma volevo solo vedere se altri hanno esperienza reale.

Come sempre apprezzare notevolmente l'input

- S

Answer 1

Io uso SQL Compare per la generazione di script quando si passa da dev -> prova -> Produzione e mi fa risparmiare tonnellate di tempo

.

Per il controllo di origine, però, usiamo SVN e ScriptDB ( http://scriptdb.codeplex.com/ ) anche se. Io uso principalmente di controllo di origine di script SQL per tenere traccia delle modifiche. Credo che il rollback di una versione del database raramente (se non mai) funziona in quanto i dati possono essere cambiati quando si effettuano modifiche alla struttura.

Questo funziona bene per alcuni dei nostri progetti in corso (più grande è 200 tabelle e 2000 sprocs). La ragione principale per fare questo però è costo in quanto i membri del team non tutti devono comprare SQL Compare (evito di aggiungere le dipendenze a progetti commerciali a meno che davvero necessario).

Answer 2

Ho aggiornato il mio post originale qui sotto per riflettere i cambiamenti nelle ultime versioni di controllo del codice sorgente SQL (3.0) e SQL Compare (10.1).

Dal momento che questa domanda è stato chiesto più di un anno fa, la mia risposta non può essere che utile a voi, ma per gli altri che possono attualmente essere valutano SSC, ho pensato di gettare i miei due centesimi. Abbiamo appena iniziato a utilizzare SQL Source Control (SSC) e nel complesso sono abbastanza soddisfatto finora. Essa ha ancora alcune stranezze, però, soprattutto se si lavora in un ambiente di database condiviso (al contrario di ogni sviluppatore che lavora a livello locale) e in particolare lavorare in un ambiente legacy dove gli oggetti nello stesso database sono divisi a caso tra i team di sviluppo.

Per dare una panoramica breve di come stiamo usando il prodotto nella nostra organizzazione, stiamo lavorando in un ambiente condiviso dove abbiamo tutte le modifiche apportate al medesimo database di sviluppo, così abbiamo attaccato il database condiviso al repository controllo del codice sorgente. Ogni sviluppatore è responsabile di apportare modifiche agli oggetti nel database tramite SQL Server Management Studio (SSMS), e quando sono finiti, essi possono commettere i loro cambiamenti al controllo del codice sorgente. Quando siamo pronti per la distribuzione ad messa in scena, il maestro build (me) fonde il ramo di sviluppo del codice del database al (messa in scena) ramo principale e quindi esegue SQL Compare utilizzando la versione principale del deposito ramo del database come l'origine e il live messa in scena del database come destinazione, e SQL Confronta genera gli script necessari per implementare le modifiche apportate per l'ambiente di staging. Messa in scena di distribuzioni di produzione funziona in modo simile. Un altro punto importante da notare è che, dato il fatto che stiamo condividendo lo stesso database con altri team di sviluppo, usiamo costruito in funzione di SSC che ti permette di creare filtri sugli oggetti di database per nome, tipo, ecc manualmente impostare filtri per gli oggetti del nostro team specifico, escludendo tutti gli altri oggetti, in modo che noi non commettiamo accidentalmente le modifiche di altri team di sviluppo quando facciamo le nostre implementazioni.

Quindi, in generale si tratta di un prodotto abbastanza semplice da configurare e utilizzare, ed è davvero bella perché si sta sempre lavorando con gli oggetti dal vivo in SSMS, al contrario di file di script disconnessi memorizzati in un repository sorgente separata che corrono il rischio di ottenere fuori sincrono. E 'anche bello perché SQL Confronta genera gli script di distribuzione per voi in modo da non dovete preoccuparvi di introdurre errori come si farebbe se si vuole creare gli script sul proprio. E come SQL Compare è molto maturo e prodotto stabile, si può sentire abbastanza sicuro che sta andando a creare gli script corretto per voi.

Con questo detto, però, qui sono alcune delle stranezze che ho eseguito in finora:

• SSC è piuttosto loquace, fuori dalla scatola, in termini di comunicazione con il server db, al fine di tenere traccia di elementi del database che sono fuori sincrono con il repository controllo del codice sorgente. Svetta ogni pochi millisecondi e se si aggiunge in più sviluppatori tutta operaia contro lo stesso database utilizzando SSC, si può immaginare che i nostri DBA non erano molto contenti. Per fortuna, si può facilmente ridurre la frequenza di polling a qualcosa di più accettabile, anche se a costo di sacrificare sensibili notifiche visive di quando gli oggetti sono stati cambiati.
• Uso della funzione di filtro oggetto, non si può facilmente capire dalla guardando oggetti in SSMS quali oggetti sono inclusi nel filtro. Quindi non si sa con certezza se un oggetto è sotto il controllo di origine, a differenza di Visual Studio, in cui vengono utilizzati per indicare le icone oggetti controllati di origine.
• L'oggetto filtraggio interfaccia grafica è molto goffo. A causa del fatto che stiamo lavorando in un ambiente di database legacy, non v'è attualmente una netta separazione tra gli oggetti che la nostra squadra possiede e quelli di proprietà di altre squadre, per cui al fine di impedirci di commettere accidentalmente / distribuzione di altricambiamenti squadre, abbiamo istituito un sistema di filtraggio per includere esplicitamente ogni oggetto specifico che possediamo. Come potete immaginare, questo diventa abbastanza ingombrante, e come la GUI per modificare i filtri è impostato per entrare in un oggetto alla volta, potrebbe diventare molto doloroso, soprattutto cercando di impostare l'ambiente per la prima volta (ho finito la scrittura di un'applicazione per fare questo). Andando avanti, stiamo creando un nuovo schema per la nostra applicazione per meglio facilitare l'oggetto di filtraggio (oltre ad essere una pratica meglio comunque).
• Utilizzando il modello di database condiviso, gli sviluppatori sono autorizzati a commettere le modifiche in sospeso a un database di origine controllata, anche se le modifiche non sono loro. SSC ti dà un messaggio di avviso se si tenta di controllare in un mucchio di cambiamenti che questi cambiamenti potrebbero non essere tuo, ma diverso da quello che si è da soli. Io in realtà trovo che questo sia uno dei più “stranezze” della SSC pericolose.
• SQL Confronto non può attualmente condividere i filtri degli oggetti creati da SSC, in modo che avrebbe dovuto creare manualmente un filtro corrispondente in SQL Compare, per cui v'è il pericolo che questi potrebbero ottenere fuori sincronia. Ho appena finito di cut-e-incollare i filtri dal file di filtro SSC sottostante nel filtro del progetto SQL Confronto per evitare di trattare con l'oggetto goffo filtraggio GUI. Credo che la prossima versione di SQL Confronta le consentirà di filtri share con SSC, così almeno questo problema è solo una breve un termine. (Nota: questo problema è stato risolto nella versione più recente di SQL Compare SQL Confrontare ora possono utilizzare i filtri degli oggetti creati da SSC.).
• SQL Compare inoltre, non può confrontare con un repository di database SSC volta lanciato direttamente. Deve essere lanciato dall'interno SSMS. Credo che la prossima versione di SQL Confronta fornirà questa funzionalità, così ancora una volta è un altro problema a breve termine. (NOTA:. Questo problema è stato risolto nella versione più recente di SQL Compare)
• A volte SQL Confronto non è in grado di creare gli script corretto per ottenere il database di destinazione da uno stato all'altro, di solito nel caso in cui si sta aggiornando lo schema delle tabelle esistenti che non sono vuoti, così attualmente si dispone di scrivere script manuali e gestire il processo di te stesso. Fortunatamente, questo sarà affrontato attraverso “migrazione script” nella prossima release di SSC, e dal guardare la versione iniziale del prodotto, sembra che l'attuazione di questa nuova funzionalità è stata ben pensato e progettato. (NOTA: la funzionalità di script di migrazione è stato ufficialmente rilasciato Tuttavia, attualmente non supporta branching Se si desidera utilizzare migrazione script, è necessario eseguire SQL confrontare con la vostra filiale codice di sviluppo originale ... quello dove.. vi registrati le modifiche ... che è piuttosto goffo e mi ha costretto a modificare il mio processo di compilazione in modo meno che ideale, al fine di ovviare a questa limitazione. Speriamo che questo sarà affrontato in una release futura.)

Nel complesso, sono abbastanza soddisfatto del prodotto e la reattività del Redgate al feedback degli utenti e la direzione che il prodotto sta prendendo. Il prodotto è molto facile da usare e ben progettato, e credo che nella prossima release o due il prodotto sarà probabilmente darci la maggior parte, se non tutti, di quello che ci serve.

Answer 3

Abbiamo effettuato una valutazione approfondita del prodotto di Red Gate e ha trovato un paio di grossi difetti. Se si vuole guardare a chi cambiato un oggetto, non si può fare senza privilegi sysadmin. Il prodotto ha bisogno di guardare la traccia sul vostro server, che richiede tali diritti. Sono in una squadra 5+ persona, e non sapere chi fosse in attesa di cambiamenti è quello che ci impedisce di utilizzare il prodotto.

Answer 4

Ho appena iniziato a lavorare per una nuova società e usano Redgate SQL controllo del codice sorgente per tutti i loro progetti, amonst loro una grande e complessa. Si fa il lavoro bene in tandem con TFS. L'unico inconveniente dal mio punto di vista è che l'integrazione di SQL Server Management Studio è altamente instabile. crash frequenti di SQL Server Management Studio accadere quando sono installati gli strumenti.