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.