Integrazione continua e consegna continua con git-flow

Question

Da un po 'di tempo eseguiamo l'integrazione continua e la consegna continua con Subversion che si attiva quando le condotte si innescano. Recentemente, abbiamo iniziato a utilizzare git in alcuni progetti con git-flow e stiamo cercando di decidere quali rami di git-flow dovremmo utilizzare per attivare l'integrazione continua e le pipeline di consegna continue.

Qui ci sono due approcci:

1. Utilizzare sviluppano ramo

Problema: Con git-flow che siamo tenuti a distribuire il rilascio (o master) filiale di produzione, in modo avremmo dovuto costruire due diversi gasdotti, uno per l'integrazione continua (sviluppo delle diramazioni) e uno per la distribuzione continua (master delle filiali). Questo potrebbe introdurre bug in produzione perché la versione in produzione non sarà la stessa di quella in altri ambienti (integrazione, test, staging).

2. Usare branch master:

Problema: In questo modo, non avremmo un'integrazione veramente continuo, dal momento che le modifiche a questi rami sono spinti non molto frequente.

Qual è il ramo di rigth da utilizzare nelle condotte?

Answer 1

La verità sta tra i due. Se si vuole adottare git-flusso in un rigoroso pipeline di CD, è necessario utilizzare il release-filiale per il vostro CI:

1. Per ogni (lotto di) sviluppare ramo commit (s), lasciare che il server CI automaticamente crea un ramo di rilascio ed esegui tutti i tuoi test su di esso.
2. Se fallisce, lascia che segnala e/o cancella il ramo, altrimenti lo unisca al master.

L'idea di base viene dalla diapositiva di John Ferguson Smart su CI/CD nei progetti Java Maven (BDD in Action, Jenkins Definite Guide).

Answer 2

A mio avviso, se si desidera applicare git-flow in Consegna continua, è necessario disporre di due pipeline diverse come si è detto nel primo approccio.

Io suggerirei di questo approccio:

1. Sviluppare ramo

• Sviluppare ramo attiverà Build Commit: Non appena una funzione viene aggiunto al ramo di sviluppare (in unione o tirare richiesta), l'IC compilerà, testerà (Test unitario & revisione del codice) e impacchetterà la soluzione (con un suffisso "-develop-vX"). Quindi il team è in grado di reagire rapidamente in caso di fallimento.
• Una volta completata la configurazione di commit, l'attività viene eseguita (in caso contrario, la modifica viene ripristinata e lo sviluppatore che ha eseguito la modifica deve correggerlo immediatamente). In parallelo, la fase di test di accettazione inizia a distribuire la build precedente nell'ambiente di sviluppo per l'esecuzione delle prove di accettazione (ad esempio il test di regressione funzionale &) senza bloccare il lavoro dello sviluppatore. Una volta terminato, lo stato del ramo di sviluppo viene comunicato al team. Pertanto, il team è a conoscenza della stabilità della soluzione durante lo Sprint corrente: se la fase Test di accettazione termina correttamente, il prodotto è pronto per la fusione con il ramo Master (in caso contrario verrà risolto).

2. branch master

• Una volta che la Sprint è finito, il ramo di sviluppo stabile (è stabile) si fonde e contrassegnata al Maestro Branch. Quindi il ramo principale attiverà il Trunk Commit Build che costruirà la soluzione, la testerà e il pacchetto per la distribuzione (il pacchetto ora è memorizzato con un release candidate o un suffisso master).
• Se il Trunk Commit Build termina correttamente (dovrebbe funzionare), la fase di test di accettazione distribuirà e convaliderà i test di accettazione in un ambiente di integrazione. E in caso di successo, la nuova versione è pronta per la produzione. In caso contrario, in caso di errore durante la fase di configurazione di commit o di accettazione, l'unione viene ripristinata.

Answer 3

Il flusso git e l'integrazione continua sono, per definizione, incompatibili. I rami sono un meccanismo per il ritardo dell'integrazione : quando si esegue il commit su un ramo diverso da master (o trunk, se si proviene da Subversion), si evita un'integrazione continua. Fare un'integrazione continua è semplice, ma non facile.