Come integrare le correzioni rapide del database di produzione nel modello di sviluppo del database condiviso? [duplicare]

10

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?

    
posta TetonSig 28.01.2012 - 18:56
fonte

3 risposte

1

Quindi ecco il mio ultimo (ultimo?) tentativo:

  • (1) Crea una correzione rapida in produzione
  • (2) Impegna tramite SSC, modifica le modifiche per produrre repository mercuriali
  • (3) Terminal Service in DEV condiviso SQL Server
  • (4) estrai il repository prod a dev e unisci le modifiche
  • (5) Vai in SSMS dove SSC è configurato come link dedicato a mercurial
  • (6) Fai un ultimo e

    • (a) spero solo di spingere il nuovo hotfix in dev perché nessuno ha cambiato gli oggetti nell'hotfix in DEV dall'ultima release
    • (b) unisci manualmente le modifiche se qualcuno ha modificato gli oggetti nell'hotfix dall'ultima versione
  • (7) commit da SSC, push a hg dev

Questo è ancora terribilmente manuale, specialmente se il passaggio 6 (b) è necessario, ma stabilisce un processo e funziona.

    
risposta data 01.02.2012 - 16:38
fonte
1

Hai un ramo di hot fix basato sulla linea principale di produzione? In tal caso, è possibile unire l'aggiornamento rapido di nuovo a Dev dopo che sono stati applicati all'ambiente di produzione.

|---Mailine 
V
| 
|------ Hot Fixes (code merged from current prod) | Ready for QA
|  ^    -----QA :
|  |            :
|  |            : QA approved and ready for Prod
|  |          V
^-------Prod    __ Hotfixes approved push back to mainline
    
risposta data 03.04.2012 - 00:50
fonte
-1

Perché no:

  1. invia le modifiche da hgprod a hgdev come suggerisci
  2. Applica automaticamente anche gli script di distribuzione (creati tra hgprod e PREPROD SQL) a DEV SQL

Questo dovrebbe significare che il "cambiamento" non appare come una differenza sul server SQL DEV.

Funzionerebbe?

    
risposta data 30.01.2012 - 12:55
fonte

Leggi altre domande sui tag