Progettazione del ramo di controllo del codice sorgente per ambienti distribuiti

Questa è la soluzione che ho trovato.

Tutti i progetti che devono essere tenuti in diversi ambienti server distribuiti avranno due rami: master e sviluppo. Il ramo principale sarà il ramo con l'ultima versione di produzione. Il ramo di sviluppo conterrà tutto lo sviluppo attivo.

Il nostro elemento di configurazione verrà collegato allo sviluppo e al ramo principale. Quando il ramo di sviluppo viene aggiornato, una build verrà creata e quindi distribuita nel server di sviluppo. Il QA verrà eseguito sul server di sviluppo. Una volta completato il controllo qualità, il ramo di sviluppo verrà unito al ramo principale.

Quando il ramo principale viene aggiornato, verrà creata una build e quindi distribuita sul server di staging. Dal server di gestione temporanea qualcuno dovrà promuovere la build per la produzione. Questo ulteriore passo è fatto per garantire che non ci sia nulla in produzione che non dovrebbe essere lì.

Quando è necessario che vengano eseguite correzioni rapide, verrà creato un ramo del master, sviluppato e una volta che l'aggiornamento rapido è stato testato localmente, verrà unito nuovamente al ramo principale. Qui qualcuno può testare l'aggiornamento rapido nell'ambiente di staging e da lì promuoverlo alla produzione.

Spero che questo aiuti chiunque.

È buona norma creare il tuo codice una sola volta e non per ambiente o ramo.

Le tue filiali GIT non dovrebbero essere direttamente collegate alle fasi dell'ambiente.

La pipeline dovrebbe essere la seguente:

sviluppa > unisci alla baseline > build > carica su repo > distribuire su dev > test > distribuire su Staging > test > approva > distribuire su 1 Prod > test > su n Prod.

Utilizza sempre lo stesso artefatto tra le promozioni. Tutti gli ambienti dovrebbero essere mirror, con le configurazioni dipendenti dall'ambiente che vengono iniettate e ridotte al minimo.

La "promozione" viene eseguita dallo strumento di distribuzione e non tramite la fusione delle branch GIT.

Applico anche il controllo qualità al prodotto completo e non ai rami delle funzionalità.

Testare le filiali nel vuoto porteranno all'integrazione o errori di fusione non trovati e un falso senso di sicurezza sulla qualità del codice. Può anche creare confusione con il Product Owner "Pensavo fosse fatto e testato? Perché otteniamo errori ora?"

Se non stai applicando l'integrazione continua, la ramificazione ha senso dividere l'aggiornamento rapido dal tuo codice più recente già sviluppato. Pertanto, inserisci semplicemente l'aggiornamento rapido nella pipeline di avvio e distribuiscilo sulla versione più recente.

Possono sorgere problemi se sono presenti modifiche all'ambiente o ai dati che non sono compatibili con le versioni precedenti tra la versione più recente e l'aggiornamento rapido.

In questo caso, in genere si include anche tutte le configurazioni di ambiente e dati come parte della "versione", quindi si ricostruisce l'intero ambiente ogni distribuzione.

Questo può essere ottenuto facilmente se i server sono virtuali o se vengono forniti tramite uno strumento di gestione della configurazione.

Esempio pratico: file vagabondo per ogni versione. Quando esegui il rollback dalla versione 1.4.5 alla versione 0.5.6, esegui il rollback della configurazione vagabonda e quindi della configurazione dell'ambiente.

Sebbene non sia il mio riferimento iniziale, qui c'è un modello di base per MSDN Team Server best practice e pattern: link Consiglio anche la lettura dei libri della serie firmata Addison-Wesley, Continuous Integration e Continuous Delivery