I DVCSes scoraggiano l'integrazione continua?

Dichiarazione di non responsabilità: lavoro per Atlassian

DVCS non scoraggia l'integrazione continua a condizione che lo sviluppatore spinga a distanza in modo regolare sul proprio ramo e che il server CI sia configurato in modo da creare i rami attivi noti.

Tradizionalmente ci sono due problemi con DVCS e CI:

• Incertezza dello stato di integrazione - a meno che lo sviluppatore non si sia unito regolarmente dal master e non esegua la build, non si sa quale sia lo stato delle modifiche combinate. Se lo sviluppatore deve eseguire questa operazione manualmente, è probabile che non venga eseguita abbastanza spesso da raccogliere i problemi abbastanza presto.
• Duplicazione e deriva della configurazione di build - se la configurazione di build deve essere copiata da una build "master" per creare una build di ramo, la configurazione per il ramo può rapidamente non essere sincronizzata con la build che era copiato da.

In Bamboo, abbiamo introdotto la possibilità per il server di build di rilevare i nuovi rami creati dagli sviluppatori e di configurare automaticamente build per il ramo basandosi sulla configurazione di build per il master (quindi, se si modifica la configurazione del master, cambia anche la configurazione dei rami per riflettere il cambiamento).

Abbiamo anche una funzione chiamata Merge Strategies che può essere utilizzata per aggiornare il ramo con le modifiche dal master prima dell'esecuzione della build del ramo o per spingere automaticamente le modifiche in un ramo build di successo da controllare, assicurando che le modifiche tra i rami siano testate insieme come presto possibile.

In ogni caso, se sei interessato a saperne di più, consulta il mio post sul blog " Rendere efficaci i rami funzione con l'integrazione continua "

Il mio piccolo team è passato a un DVCS un anno o due fa, e il resto della mia azienda ha seguito l'esempio un paio di mesi fa. Nella mia esperienza:

• Le persone che utilizzano un VCS centralizzato tendono ancora a tenere a bada i commit quando stanno facendo un grande progetto. Questo non è un problema unico per DVCS. Avranno set di modifiche che attendono diversi giorni prima di eseguire un commit. La grande differenza è che se in un dato momento fanno un errore o se il computer si blocca, richiede molto più impegno per risolverlo.
• Usiamo un flusso di lavoro di commit in cui ogni sviluppatore lavora sul proprio ramo denominato e solo la persona che ha revisionato il proprio codice è autorizzata a unire le proprie modifiche in testa. Questo riduce la probabilità che un commit causi problemi, quindi le persone prestano davvero attenzione quando il server di generazione genera un messaggio di errore. Significa anche che altri sviluppatori possono continuare a lavorare sui propri rami fino a quando la testa viene riparata.
• Su un DVCS, le persone tendono a dedicare più tempo alla programmazione prima di unire il loro codice con la testa. Quindi tende a introdurre un piccolo ritardo nella continuità della build. Ma la differenza non è abbastanza significativa per contrastare i vantaggi del DVCS.

Recentemente ho osservato circa 19 progetti che hanno utilizzato Mercurial rispetto a SubVersion (I was un geek sovversione ): gli sviluppatori hanno iniziato a diventare veramente individualisti lavorando sulla propria filiale e integrandosi solo dopo giorni o settimane server. Ciò ha causato gravi problemi di integrazione e preoccupazioni.

Un altro problema che abbiamo dovuto affrontare è il server di integrazione continua. Siamo stati informati dei problemi (test di errore, ad esempio), solo quando la sincronizzazione dei commit è stata effettuata sul server.

Sembra che Martin Fowler abbia scritto a riguardo sul suo sito.

Detto questo, alcuni dei progetti che menziono hanno fatto una sincronizzazione almeno una volta al giorno riducendo i problemi. Quindi, per rispondere alla tua domanda, penso che DVCS possa scoraggiare l'integrazione continua e aumentare l'individualismo. Tuttavia, DVCS non è la causa diretta.

Lo sviluppatore è ancora in carica indipendentemente dal VCS che usano.

L'idea su cui basi il tuo ragionamento è molto traballante, parlando a bassa voce. È compito del team / gestione / processo che lo sviluppatore possa attendere fino al completamento del compito .

Facendolo in un modo o nell'altro, "aspetta" o "sbrigati", tronco condiviso o ramo isolato, è noto come strategia di ramificazione e se tu informazioni di studio disponibili online , scoprirai che la scelta di una particolare strategia ha fondamentalmente niente a che fare con VCS centralizzato o distribuito.

Ad esempio, per VCS distribuiti come Mercurial, puoi trovare facilmente un strong suggerimento per fusioni frequenti :

First, merge often! This makes merging easier for everyone and you find out about conflicts (which are often rooted in incompatible design decisions) earlier...

Studiando le raccomandazioni come sopra, si può facilmente scoprire che queste fanno appello a considerazioni che non hanno nulla a che fare con la distribuzione di Mercurial.

Ora, diamo un'occhiata alla situazione a lato del VSC centralizzato, Subversion. Studiando le informazioni online, è possibile trovare tra le migliori strategie popolari chiamate trunk stabili e trunk instabile - ognuna con un impatto opposto sulla frequenza delle unioni. Vedete, le persone scelgono l'uno o l'altro modo di fare le cose senza nemmeno prestare attenzione alla centralizzazione di VCS.

• ^{Ho visto verificarsi fusioni molto ritardate (anche incoraggiate dalla gestione dello zoppo) con VCS centralizzato, così come frequenti fusioni fatte con DVCS quando team / management pensava che fosse la strada giusta. Ho visto che a nessuno importa se VCS è distribuito o centralizzato al momento di decidere in un modo o nell'altro.}

Dato sopra, sembra che la risposta giusta a I DVCS scoraggiano l'integrazione continua? sarebbe Mu .

VCS che viene distribuito o meno non ha un impatto sostanziale su questo.

La mia esperienza è il esatto opposto , i team che usano svn non inseriscono push per giorni, perché il codice su cui stavano lavorando avrebbe causato il non compilare del tronco per tutti gli altri senza perdere tempo con la fusione manuale. Poi, verso la fine dello sprint, tutti si impegnerebbero, la follia sarebbe avvenuta, le cose sarebbero state sovrascritte e perse e dovevano essere recuperate. Il sistema CI diventerebbe ROSSO e ne risulterebbe il puntamento del dito.

Non ho mai avuto questo problema con Git / Gitorious.

Git ti consente di estrarre e unire le modifiche di altre persone a tuo piacimento, non perché qualcun altro ha controllato qualcosa e vuoi effettuare il check-in ma hai 20 minuti di fusione manuale da fare.

Git ti consente anche di eseguire il commit di tutti gli altri, unire il tuo codice e quindi inviare una versione funzionante a tutti gli altri in modo che non debbano indovinare cosa dovrebbero avere per unire in base a ciò che hai cambiato.

Avere qualcosa come Gitorious come mediatore per le revisioni del codice tramite unire le richieste rende la gestione di molti rami e molti contributori molto indolore.

Configurare Jenkins / Hudson per tenere traccia di tutti i rami attivi in un repository Git è molto semplice. Abbiamo ottenuto più trazione con CI e feedback più frequenti sullo stato dei repository quando ci siamo trasferiti a Git da SVN.

I server di creazione sono economici. Basta che il tuo server CI riprenda tutti i rami che conosci.

Jenkins ha il supporto per controllare più repository git e ottenere gli ultimi da uno di quelli in un singolo lavoro. Sono sicuro che esistono soluzioni simili con altri strumenti.

Questa vecchia domanda è appena stata contrassegnata come duplicata di una nuova, e dal momento che molte risposte fanno riferimento a idee obsolete, ho pensato di postarne una aggiornata.

Una cosa che apparentemente non era molto comune cinque anni fa stava eseguendo test CI su rami di richiesta pull prima di unirli a master. Penso che questo rifletta un atteggiamento mutevole che sebbene la fusione frequente sia desiderabile, la condivisione di ogni cambia con tutti , non appena lo si fa , isn ' t ottimale.

DVCS ha generato una modalità più gerarchica di integrazione dei tuoi commit. Ad esempio, lavoro spesso a stretto contatto con lo sviluppatore che siede accanto a me. Tireremo i rami l'uno dell'altro più volte al giorno. Oggi, abbiamo collaborato con un altro sviluppatore tramite modifiche inviate a una richiesta pull ogni poche ore.

Stavamo apportando ampie modifiche agli script di compilazione. Jenkins riunisce localmente ogni ramo PR con master ed esegue test, quindi abbiamo ottenuto feedback automatici in questo modo, senza disturbare nessun altro sviluppatore che necessitava di una build pulita. Probabilmente ci vorrà ancora un altro giorno prima che il PR sia pronto per unire e padroneggiare al di fuori del nostro gruppo di tre sviluppatori.

Tuttavia, se qualcuno non può aspettare che le nostre modifiche si uniscano al master, poiché il loro cambiamento dipende dal nostro, possono unire il nostro ramo dev localmente e continuare con il loro lavoro. Questo è ciò che molte persone che sono abituate a CVCS mancano. Con CVCS, il modo solo di condividere le tue modifiche è di unirle nel repository centrale, ed è per questo che la fusione spesso è più critica. Con DVCS, hai altre opzioni.

Direi che il DVCS è più favorevole all'integrazione continua. Le fusioni non sono così irritanti con loro. Richiede però più disciplina. Dovresti seguire un commit locale con un pull dalla base per unire e quindi premere quando l'attività è completa (prima di passare alla successiva).

Quando il mio team è passato a Git, abbiamo presentato esplicitamente il nostro processo in modo tale che una spinta doveva essere trattata esattamente come un commit nel vecchio VCS, e i commit locali potevano essere eseguiti con frequenza / raramente come ogni individuo ha scelto. Con questo, non vi è alcuna differenza nel sistema CI se stiamo usando un DVCS o un VCS centralizzato.

La risposta è sì e no.

La differenza qui è tra l'invio diretto al repository centrale con visualizzazione in CI e l'invio delle modifiche al repository centrale visualizzato in CI. Il "problema" che potresti trovare è che gli utenti di DVCS potrebbero non eseguire tale push regolarmente.

Direi che questa è una caratteristica intrinseca del design di un DVCS, non è progettata per trasmettere le modifiche al server centrale in ogni momento - se lo fosse, si potrebbe anche usare un CVCS. Quindi la risposta è quella di imporre un flusso di lavoro migliore tra i tuoi sviluppatori. Di 'loro di cambiare i cambiamenti ogni sera. Semplici!

(e se i tuoi utenti SVN non si impegnano tutte le sere, diglielo - è esattamente lo stesso problema).

Git non impedisce l'integrazione continua. Il flusso di lavoro basato su trunk è.

Questo può sembrare controintuitivo, ma: se gli sviluppatori lavorano su feature branch, possono essere incoraggiati a integrarsi frequentemente sulle proprie macchine (e sono obbligati a farlo prima di inviare le loro funzionalità per l'unione). Al contrario, un flusso di lavoro basato su trunk favorisce i commit più grandi e quindi un'integrazione meno frequente.

Ritengo che un flusso di lavoro basato su trunk in stile Google sia controproducente con un VCS come Git, in cui la fusione è semplice. Ecco cosa consiglierei invece:

• Rompi le caratteristiche abbastanza piccole da non impiegare più di un giorno o due per svilupparle.
• Ogni funzionalità è sviluppata su una filiale privata.
• Lo sviluppatore si integra frequentemente sul ramo privato ( git fetch origin; git merge master ). Di solito faccio questo più volte al giorno quando lavoro in questo modo.
• Quando lo sviluppatore inoltra il ramo per l'unione e la revisione, il server CI esegue una compilazione automatica. Unisci accade solo quando questo passa.

Quindi ce l'hai: piccoli commit, integrazione frequente e una cronologia tracciabile di ciò che è appartenuto a quale caratteristica. I rami, usati correttamente, sono la chiave di tutto ciò che vale Git, quindi evitarli è un grosso errore.

Ci sono soluzioni tecniche fantastiche come @jdunay menzionate, ma per noi è un problema di persone - nello stesso modo in cui promuovere un ambiente in cui le persone si impegnano a svn spesso è un problema di persone.

Ciò che ha funzionato per noi è: (sostituisci "master" con il ramo dev attivo corrente)

1. Fusione / rebase frequenti dal master
2. Spinte abbastanza frequenti da padroneggiare

3. Consapevolezza delle cose che causano l'inferno di fusione, come certi refactoring e attenuazione di ciò comunicando. Ad esempio:

   • Assicurati che tutti spingano prima di pranzo
   • Esegui e spinge il refactoring durante il pranzo
   • Assicurati che tutti tirino dopo pranzo