Branching interrompe l'integrazione continua?

Prima di tutto, l'uso di feature branch (per isolare il lavoro svolto su una funzione) e CI (per trovare i problemi di integrazione non appena vengono commessi) sono leggermente in disaccordo.

A mio parere, l'esecuzione di elementi di configurazione su feature è una perdita di tempo. Poiché i rami delle funzionalità vanno e vengono frequentemente, gli strumenti CI dovrebbero essere riconfigurati più e più volte. E quello per un ramo che molto probabilmente riceve solo gli aggiornamenti da una o due fonti che coordinano i loro check-in per evitare i problemi che un sistema CI deve rilevare.
Pertanto, non è necessario avere i branch delle funzionalità sul server del repository principale.

Come per le domande 1 e 3: è responsabilità dello sviluppatore assicurarsi che la build sul ramo di sviluppo principale non si interrompa quando si uniscono il loro ramo di funzione in esso. Come fanno questo è il loro problema, ma due possibili modi sono:

• Estrai regolarmente le modifiche apportate al ramo di sviluppo principale nel ramo delle funzioni (ad esempio ogni giorno)
• Una volta terminata la funzione, unisci il ramo di sviluppo principale al ramo della funzione e premi il risultato della fusione sul ramo di sviluppo principale.

In entrambi i casi, gli evidenti problemi di integrazione (ad esempio classi / file rinominati) vengono trovati e risolti per primi sul ramo di funzionalità. È probabile che i problemi più sottili vengano rilevati solo quando viene eseguita la compilazione notturna e dovrebbero essere risolti lì e poi.

In risposta a 1)

Qualsiasi modo funziona è un buon modo. Tuttavia : l'intera premessa dell'integrazione continua consiste nell'integrare continuamente . L'idea è di catturare i bug di integrazione non solo il prima possibile, ma all'interno del ciclo di feedback di sviluppo - cioè, mentre tutti i dettagli per il codice in prova sono nella memoria a breve termine dello sviluppatore che apporta le modifiche. Ciò significa che, in normali circostanze quotidiane, il lavoro deve essere integrato tra i rami di funzionalità su ogni commit, forse una volta ogni 15 minuti o giù di lì. Per ribadire: lo scopo principale dell'integrazione continua è di esporre i bug di integrazione, mentre tutti i dettagli sono nella memoria a breve termine degli sviluppatori che apportano le modifiche.

2)

Per lo più, le ramificazioni vengono create in Mercurial mediante la clonazione dei repository, quindi non è necessario assegnare a ogni sviluppatore i privilegi di commit per il repository master. Probabilmente, tuttavia, si vuole dare agli sviluppatori la possibilità di creare repository clonati sul server di integrazione continua, poiché non è sempre possibile eseguire test localmente. (Una volta avevo un sistema CI in cui i test di unità impiegavano 8 ore per funzionare su un cluster di 128 core). Inutile dire che gli sviluppatori non lo facevano, non potevano eseguire test localmente.

3)

Se hai le risorse computazionali per questo, sì, gli sviluppatori dovrebbero essere sempre aggiornati con la linea principale di sviluppo in ogni momento, in particolare prima di lasciare il lavoro, e dovresti eseguire test notturni su tutte le linee di sviluppo (sebbene la maggior parte dei sistemi CI non lo rende facile).

Ecco come puoi farlo: feature branching.

1. Per qualsiasi nuova attività (bugfix, funzionalità, ecc.) avvia un nuovo ramo (ad esempio bugfix-ticket123-the_thingie_breaks)
2. Mentre lavori, aggiorna e unisci continuamente default (o master in git) nel tuo ramo delle funzioni . Questo ti aiuta ad avere il tuo ramo aggiornato senza dover lavorare nel ramo predefinito
3. Quando la tua funzione è pronta e i tuoi test di unità passano , quindi tira e unisci di default nel tuo ramo ancora una volta, chiudi il tuo ramo e spingilo senza unire , il tuo integratore noterà il nuovo capo e che è un ramo chiuso, quindi si prenderà cura di integrarlo. Se non hai un integratore, passa a quello predefinito e unisci il ramo della funzione in default .

La cosa importante qui è che avrai 0 conflitti nel ramo predefinito quando unisci il tuo ramo di funzione al suo interno e tutti i tuoi test passano .

Con questo semplice flusso di lavoro avrai sempre un ramo predefinito incontaminato e stabile, ora fa lo stesso per i rami di rilascio, ma l'integrazione è predefinita . Se devi integrare gli hotfix direttamente nei rami di rilascio, puoi farlo saltando il ramo predefinito, ma di nuovo, selezionando solo i rami appena aggiornati dal ramo di destinazione e senza conflitti e passando i test delle unità.