L'introduzione di un ramo Dev da lungo tempo creerà inutili spese generali di manutenzione?

0

Sto vedendo le cattive pratiche che si verificano nel controllo della versione in cui i miei colleghi stanno creando il proprio sistema di controllo delle versioni con stored procedure in modo che possano confrontare i risultati prima / dopo le modifiche e finiamo con più stored procedure nel database con nomi leggermente diversi per esempio StoredProcedureV1, StoredProcedureV2

Sto prendendo in considerazione l'idea di introdurre una filiale Dev di vecchia data come soluzione suggerita per risolvere questa pratica e supportarmi anche nell'introduzione del monitoraggio degli articoli di lavoro e delle revisioni del codice. Il ramo avrebbe una pipeline CI / CD per costruire e distribuire le modifiche alla nostra istanza SQL di dev / test condivisa. I changeset sarebbero quindi promossi con un'unione in Main che avrebbe una pipeline CI / CD simile da distribuire al server di produzione.

Questo creerà un sovraccarico di manutenzione non necessario (probabilmente per me) eseguendo le fusioni da Dev a Main per un piccolo vantaggio?

Lo stesso potrebbe essere ottenuto attraverso versioni manuali / approvate? Oppure manca di flessibilità perché capisco che tutti i changeset sul ramo sarebbero stati rilasciati.

Sfondo

Siamo una piccola squadra (attualmente 3 membri dello staff) che sono responsabili dello sviluppo dell'ambiente Data Warehouse dell'organizzazione.

Il nostro sviluppo è fatto in Visual Studio 2017 / SQL Server Data Tools e abbiamo utilizzato TFVC in VSTS / Azure DevOps per circa un anno, per tutti coloro che sono coinvolti questa è la nostra prima esposizione al controllo della versione.

Tutti i progetti sono conservati in un repository con un ramo principale, ho usato filiali occasionalmente per grandi cambiamenti ma non fanno parte di un flusso di lavoro comune e i miei colleghi usano solo il ramo principale.

Abbiamo due server disponibili ciascuno con la propria istanza di SQL Server uno come produzione e l'altro considerato come dev / test. Le istanze locali al momento non sono un'opzione a causa delle dimensioni dei database e delle risorse richieste per soddisfare i requisiti di governance delle informazioni per un ambiente locale.

Al momento l'istanza di dev / test non viene utilizzata in modo efficace, fondamentalmente è un ambiente per la nostra prima versione di una pipeline CI / CD per distribuire prima le modifiche di dacpac e poi nell'ambiente di produzione.

Ci sono problemi fondamentali con il nostro flusso di lavoro in quanto non ce n'è uno vero, a parte il check-in di un changeset e la pipeline CI / CD, che riconosco è colpa mia. Non stiamo facendo uso del monitoraggio degli oggetti di lavoro, non esiste un processo di revisione del codice e c'è poca documentazione. I test vengono eseguiti manualmente, ma nessuno ha ancora capito come eseguire i test automatizzati con i progetti che stiamo utilizzando.

Come guida, la mia mancanza di esperienza e di fiducia in queste aree mi trattiene dall'introdurre queste cose, ma i cambiamenti devono essere introdotti gradualmente.

Per il particolare problema con i miei colleghi che introducono il proprio sistema di controllo delle versioni, sento che ho bisogno di essere in grado di presentare una soluzione adatta prima di affrontare la pratica.

    
posta mheptinstall 08.11.2018 - 23:24
fonte

2 risposte

1

Avere un ramo dev è molto comune e l'unione con il master dovrebbe essere senza problemi, purché si assicurino che tutte le modifiche passino attraverso dev e non siano fatte direttamente per diventare master.

Tuttavia, non eliminerà necessariamente il problema sprocV1 sprocV2.

A volte, per avere zero tempi di fermo, devi avere entrambe le versioni sproc live nello stesso momento.

Per assicurarti che non siano necessari o che, in seguito, siano stati ripuliti, devi seguire la procedura di rilascio.

    
risposta data 09.11.2018 - 07:40
fonte
0

A parte il caso di hot cut-over, penso che il problema qui sia il test. I tuoi sviluppatori vogliono sapere che non stanno rompendo nulla a livello di database, ed essenzialmente eseguono entrambi i proc e confrontano i risultati, o lasciano andare in modo che possano tornare indietro senza generare incidenti.

Per il processo dell'incidente, vedi cosa puoi fare per rendere meno gravi gli incidenti / i problemi.

Al problema del test. Esegui un processo di test, che può essere eseguito su richiesta / notte qualunque sia la cadenza migliore.

Suppongo che tu abbia un comando che:

  • distribuire un database, incluso l'esecuzione in migrazioni di dati, modifiche dello schema e nuovi processi memorizzati.
  • backup e ripristino di un database.
  • avere accesso a un database equivalente di produzione completo / ridotto / ridotto.
  • ha una cartella di test del database, con i tuoi test codificati come stored procedure sql.

scrivi uno script (o trova quello di qualcun altro) che:

  1. distribuisce il database "prod-like"
  2. snapshot del database.
  3. seleziona una stored procedure, eseguila, eseguila, acquisisci tutti i set di risultati di output in un formato tabulare, una tabella per set di risultati.
  4. reimposta il database allo snapshot.
  5. ripetere dal punto 3 per ciascun test.
  6. aggiorna il database
  7. snapshot del database
  8. seleziona una stored procedure, eseguila, eseguila, acquisisci tutti i set di risultati di output in un formato tabulare, una tabella per set di risultati.
  9. reimposta il database allo snapshot.
  10. ripetere dal punto 8 per ciascun test.
  11. usa uno strumento diverso su ogni coppia di risultati. Se sono identici, il test è passato. altrimenti hanno fallito.
  12. Crea un rapporto di prova utilizzando un formato standard
  13. aggiungi report e file di output al tuo lavoro ci / cd
  14. notifica agli sviluppatori di un test fallito.
risposta data 09.11.2018 - 09:24
fonte

Leggi altre domande sui tag