Utilizziamo SQL Source Control 3, SQL Compare, SQL Data Compare da RedGate, repository Mercurial, TeamCity e un set di 4 ambienti inclusa la produzione.
Sto lavorando per portarci in un ambiente dedicato per sviluppatore, ma per almeno i prossimi 6 mesi siamo bloccati con un modello condiviso.
Per riassumere il nostro sistema attuale, abbiamo un server DEV SQL in cui gli sviluppatori apportano prima modifiche / aggiunte. Commettono le loro modifiche tramite SQL Source Control a un repository hgdev locale. Quando eseguono un push di hg nel repository principale, TeamCity lo ascolta e quindi (tra le altre cose) spinge il repository hgdev a hgrc. Un altro processo di TeamCity lo ascolta e fa un pull da hgrc e distribuisce l'ultimo a un server SQL QA in cui vengono eseguiti test di regressione e integrazione. Quando questi vengono passati, si verifica una spinta da hgrc a hgprod. Facciamo un confronto di hgprod con il nostro SQL Server PREPROD e generiamo script di deployment / rollback per il nostro rilascio di produzione.
Separato da quanto sopra abbiamo le correzioni rapide del database che dovranno essere applicate tra una release e l'altra. Il processo in cui il nostro team operativo apporta modifiche al database PreProd e, dopo il test, utilizza il controllo origine SQL per inviare le modifiche hot fix a hgprod dal database PREPROD e quindi effettuare un confronto da hgprod a PRODUCTION, creare l'implementazione script e eseguili su PRODUCTION.
Se fossimo in un database dedicato per modello di sviluppatore, potremmo semplicemente spingere hgprod automaticamente indietro a hgdev e unirmi alla hot fix change (tramite il monitoraggio di TeamCity per i check hgprod) e quindi gli sviluppatori lo raccolgono e lo uniscono al loro repository locale e database periodicamente.
Tuttavia, dato che con un modello condiviso il database DEV stesso è la fonte di tutte le modifiche, questo non funzionerà. L'invio degli hotfix a hgdev verrà visualizzato in SQL Source Control come diverso da DEV SQL Server e pertanto è necessario sovrascrivere il reposistory con "change" da DEV SQL Server.
Il mio unico rimedio finora è che OPS assegna a uno sviluppatore il ticket dell'hotfix con uno script allegato e poi eseguiamo i loro hotfix contro DEV stessi per unirli nuovamente.
Non sono contento di questa soluzione. Oltre a lavorare più velocemente per raggiungere un ambiente dedicato, sono altri modi per mantenere questo ciclo automaticamente?