DVCS come Git è inappropriato per i team che utilizzano l'integrazione continua?

Question

I processi di sviluppo del mio team sono basati su continuous integration. Gli unici rami che creiamo sono rami di manutenzione quando rilasciamo, ma altrimenti ci si aspetta che gli sviluppatori si impegnino regolarmente (quotidianamente se non più spesso) in trunk, in modo che il lavoro di tutti sia sempre integrato, continuamente testato e tutte quelle cose buone.

La mia comprensione di DVCS è che è ideale per la ramificazione. Ho lavorato alcuni anni fa in un team in cui ciò sarebbe stato molto utile, poiché ogni fase di sviluppo è stata eseguita su un ramo e si sono fuse solo una volta completate e testate. Ma questa era una filosofia diversa dall'integrazione continua.

Ma mi sembra che per una squadra che utilizza integrazione continua, le caratteristiche groove di strumenti DVCS come Git non sarebbe particolarmente rilevante, e potrebbe anche ostacolare il processo di integrazione continua se la fusione cambiamenti richiede passaggi aggiuntivi che possono essere dimenticati .

Sono sicuro che ci sono altri vantaggi di un DVCS (ad esempio, commettere è molto veloce perché è locale, presumibilmente si fonde con il ramo principale potrebbe accadere in background mentre lo sviluppatore continua a lavorare).

Ma per questa domanda, sono interessato a come i team che utilizzano DVCS e l'integrazione continua riconciliano le due filosofie apparentemente in conflitto. Sono principalmente interessato a sentire da persone che stanno effettivamente facendo questo.

Answer 1

In realtà DVCS ha reso l'integrazione continua molto più semplice.

Con VCS centrale, ogni sviluppatore ha i diritti di eseguire il commit direttamente nel trunk e quindi può eseguire il commit del codice buggy. CI lo rileverà dopo il fatto. Quindi è possibile avere un tronco rotto anche con CI.

D'altra parte, le operazioni di base nel mondo DVCS sono ramificazioni e fusioni. Poiché l'unione è esplicita e un processo separato rispetto al commit sul trunk, è sempre possibile verificare il risultato di un'unione prima dello che atterra sul trunk. Non ho esperienza con Git, ma gli sviluppatori di Bazaar VCS hanno utilizzato questa tecnica con successo per almeno 3,5 anni con l'aiuto dello strumento PQM.

Fondamentalmente PQM flusso di lavoro si presenta come segue: sviluppatore pubblica il suo ramo in modo che possa essere fusa, poi invia uno speciale e-mail al bot PQM con le istruzioni di unione. Quando PQM riceve una richiesta di unione, crea un ramo di integrazione separato (copia del trunk), quindi unisce il ramo dello sviluppatore ed esegue test sul codice risultante. Se tutti i test vengono passati, il ramo di integrazione viene trasferito al trunk, altrimenti lo sviluppatore riceverà un messaggio di posta elettronica con il log dei test in errore.

L'esecuzione di tutti i test per il progetto Bazaar richiede tempo, ma i test vengono eseguiti su richiesta su un server separato. Gli sviluppatori non saranno bloccati dalle fusioni e potranno continuare a lavorare su altre attività.

Come risultato del flusso di lavoro di unione basato su PQM, il trunk bzr non viene mai interrotto (almeno finché ci sono abbastanza test di accettazione e di regressione).

Answer 2

Poiché tutti i DVCS possono essere utilizzati con un flusso di lavoro che utilizza un repository centralizzato, non ci sono problemi. La politica impone che lo sviluppatore debba trasferire le proprie modifiche al repository centrale esattamente nello stesso modo in cui la policy impone il commit a un VCS non distribuito. Gli strumenti aggiuntivi che consentono allo sviluppatore di modificare i set di patch non sono in alcun modo un ostacolo e, di fatto, rendono molto più facile generare una base di codice gestibile.

Answer 3

Gli strumenti di integrazione continua come Hudson supportano DVCS, quindi sospetto che sia possibile conciliare l'integrazione continua con il controllo della versione distribuita.

In primo luogo, penso che con DVCS che utilizza flussi di lavoro come il flusso di lavoro di un ramo di argomenti l'IC potrebbe essere meno necessario. In secondo luogo, è possibile impostare un repository di integrazione continua (singolo, centrale) a cui si spinge quando si è pronti e gli hook fanno CI.

---

Aggiunto 07-08-2009:

Si veda ad esempio Continuous Integration Spring Cleaning post su GitHub Blog.

Answer 4

L'utilizzo di un DVCS come Git non impedisce di eseguire regolarmente il commit su un archivio centrale. Tuttavia, ciò significa che è possibile eseguire commit intermedi localmente e solo dopo aver apportato le modifiche al repository centrale, una volta terminato.

In questo modo si hanno i vantaggi del controllo del codice sorgente anche quando si sta implementando a metà strada una funzionalità, senza interrompere la creazione per gli altri sviluppatori.

Answer 5

Due idee che ho trovato aiuto al spiega questo:

• DVCS separano impegna da unioni.
• CI viene eseguito contro un repository che si sceglie.

Quindi il nocciolo della questione è il modo in cui le unioni vengono create nei repository su cui si desidera eseguire uno strumento CI. Puoi scegliere di avere un solo repository quando inizi.