Baby sitter del tuo sistema di integrazione continua

Uno dei miei ruoli nel mio team è la persona di costruzione . Sono responsabile di mantenere / aggiornare i nostri script di build e di assicurarmi che stiamo costruendo "senza intoppi" sul server di integrazione continua. Di solito questo lavoro non mi dispiace, anche se spesso mi sembra di fare da babysitter costantemente al server CI.

Questo lavoro a volte può essere fastidioso perché se la build si interrompe, devo abbandonare la storia su cui sto lavorando e indagare sul fallimento della build. Gli errori di costruzione si verificano quotidianamente nel nostro team. A volte gli sviluppatori semplicemente non creano localmente prima di eseguire il commit, quindi i test falliscono sul server CI. In questa situazione, mi piace raggiungere rapidamente la persona che ha avuto il "cattivo commit" in modo che la build non rimanga interrotta troppo a lungo. A volte (molto meno frequentemente) esiste una strana condizione sul server CI che deve essere sottoposta a debug.

So che molti team maturi usano l'integrazione continua ma non ci sono molti materiali disponibili sulle buone pratiche.

I miei problemi indicano che la nostra continua integrazione non è molto matura o fa semplicemente parte del lavoro?

Quali sono alcune buone pratiche da seguire? Quali sono le caratteristiche dell'integrazione continua matura ?

Aggiornare

Invece di rispondere ad alcuni commenti, farò invece un aggiornamento. Abbiamo un solo, semplice comando che fa esattamente quello che farà il server di compilazione durante la creazione dell'app. Compilerà, eseguirà tutte le unità / l'integrazione e alcuni rapidi test basati sull'interfaccia utente.

Leggendo le risposte di tutti, sembra che potremmo avere due problemi principali.

1. Server CI non si lamenta abbastanza forte quando un build fallisce.
2. Gli sviluppatori non hanno la responsabilità di tutti di assicurarsi che il loro impegno sia andato a buon fine.

Ciò che rende le cose più difficili nel mio team è che abbiamo un grande team (10+ sviluppatori) E abbiamo un paio di membri del team offshore che si impegnano quando non siamo nemmeno al lavoro. Poiché la squadra è numerosa e abbiamo stabilito che si preferiscono piccoli e frequenti commit, a volte abbiamo davvero molta attività in un giorno.

Innanzitutto: ogni persona è responsabile del processo di creazione . Sembra che i membri del tuo team non siano maturi ... Nessuno se la cava con la scrittura del codice e lo spegne sul server CI sperando che funzioni. Prima di eseguire il commit del codice, è necessario verificarlo sul proprio computer locale. Dovresti essere sicuro che il codice che stai effettuando non interromperà la creazione. Naturalmente, ci sono casi in cui la compilazione si interrompe involontariamente (ad es. Se un file di configurazione è stato modificato o il commit sciatto è stato inavvertitamente effettuato).

La maggior parte dei server CI (ho usato solo Hudson) invierà un'e-mail automatica con i dettagli degli commit effettuati che hanno causato l'interruzione della build. L'unica parte del tuo ruolo è stare dietro di loro con un aspetto duro fino a quando il sospetto non risolverà qualunque cosa abbiano rotto.

La tua squadra ha sbagliato una cosa:

Essere responsabili del server di compilazione non equivale a essere responsabili della build .

È responsabilità della persona che effettua il check-in del codice per farlo "funzionare" (per un certo valore del lavoro). L'unico motivo per avere un server di build è quello di sorvegliare le supervisioni in questo processo. Qualsiasi server di compilazione degno di nota può informare le persone che hanno effettuato il check-in dall'ultimo build (nonché chiunque altro sia interessato) con le seguenti informazioni:

• Build rotto!
• Cosa è andato storto durante la costruzione!
• Cosa è cambiato dall'ultima build!

Questo accade molto spesso via e-mail. È importante che ciò avvenga abbastanza rapidamente dopo ogni check-in.

La persona può quindi vedere cosa è andato storto e risolverlo, quindi il server di build notifica a chiunque sia interessato che la build è tornata alla normalità. Questo dovrebbe accadere da solo senza alcun coinvolgimento degli altri, ma i colpevoli del check-in.

Quindi, per rispondere alla tua domanda: un ambiente CI maturo NON richiede il coinvolgimento di un bidello nel suo normale funzionamento.

Inoltre, se le "condizioni strane esistono" si verificano molto frequentemente, scopri la causa e rendi il sistema più robusto.

Cambia il processo. Se un commit interrompe la build, ripristina automaticamente tale commit e avvisa lo sviluppatore che l'ha interrotto. È sciocco consentire a un membro del team un errore di rallentare il resto del team. O invece di eseguire automaticamente build di integrazione, chiedi agli sviluppatori di controllare la macchina di integrazione e, se la build ha esito positivo, possono eseguire il commit. L'integrazione continua non significa "controlla qualunque spazzatura ti piaccia e qualcuno lo risolverà per te".

La strategia del "ramo d'oro" non funziona se non esiste un gatekeeper per il ramo d'oro.

Un DVCS come Git potrebbe aiutare; invece di eseguire il commit, lo sviluppatore può semplicemente inviare un changeset per l'integrazione al server CI e il server può quindi tentare di integrare il changeset. Se l'integrazione ha esito positivo, il changeset viene unito e, in caso contrario, viene rifiutato.

Un problema che vedo spesso è che gli sviluppatori non possono eseguire una build locale che ha esattamente gli stessi passaggi di una build CI. Cioè, il server CI è configurato per includere passaggi aggiuntivi come test unità / integrazione, copertura, ecc. Che non possono essere eseguiti localmente. Inevitabilmente, gli sviluppatori saranno morsi da uno dei passaggi che non possono eseguire localmente e inizieranno a chiedersi perché si preoccupano di creare una versione locale prima del check-in.

Tengo la mia intera build autonoma e il server CI avvia semplicemente una build di rilascio senza configurazione / passaggi estranei definiti. Gli sviluppatori possono eseguire una build di rilascio localmente prima del check-in che include tutti i passaggi che verranno eseguiti dalla build dell'elemento della configurazione ed essere molto più sicuri che nulla si interromperà quando effettuano il check-in.

Ulteriori vantaggi di questo approccio includono:

• è facile passare da un server CI all'altro perché non hai investito molto tempo nella configurazione di passaggi estranei
• tutti gli strumenti di build-time sono sotto il controllo del codice sorgente, il che significa che tutti gli sviluppatori stanno usando esattamente lo stesso set di strumenti per costruire il tuo sistema
• oltre al punto precedente, è semplice modificare gli strumenti di costruzione in modo controllato

PS. l'intero concetto di babysitter build è ridicolo, ma altri lo hanno coperto.

Prima di tutto, gli sviluppatori non dovrebbero interrompere regolarmente le build, ma dovrebbero creare ed eseguire i test localmente prima di impegnarsi nel ramo CI. Dovrebbe essere un segno di vergogna rompere la build, ed è importante applicarlo. L'ho fatto attraverso la pubblicazione di statistiche e ho visto che altri team hanno una "borsa della build" in cui si mette un dollaro ogni volta che si interrompe la build. Alla fine del progetto quei soldi vanno alla birra.

Se la vergogna / l'orgoglio personale non funzionano, potrebbe essere necessario passare a cose più pesanti (ad esempio la risoluzione minacciosa). Interrompere la costruzione prima di partire per la giornata dovrebbe essere un'offesa importante. E ogni sviluppatore dovrebbe avere una notifica sullo stato della build sul proprio desktop. La parte migliore di tutto ciò è che incoraggia piccoli impegni, che sono comunque preferiti.

Detto questo, a volte la compilazione si interromperà (motivi di configurazione dell'IC, ad esempio). E a volte le persone si rovinano e se ne vanno per il giorno con la build rotta. Ecco perché dovresti puntare a un processo che consenta il rollback rapido e semplice di versioni conosciute. Se riesci sempre a eseguire il rollback dell'ultima build valida (e fare in modo che la versione ripristinata venga distribuita in tutti i luoghi necessari), nel caso peggiore di una build interrotta in cui il colpevole è partito per la sera, puoi rotolare tornare all'ultima buona versione e urlare a lui / lei al mattino.

Non posso raccomandare abbastanza il libro di consegna continua . Se stai cercando una guida su come maturare il tuo processo CI, provalo.

Ho sentito di una cosa che Microsoft (forse?) Fa, che è avere il ruolo di costruire una baby-sitter in giro per il team. Il modo in cui lo fanno è che quando qualcuno rompe la build (che dovrebbe probabilmente includere il check-in in qualcosa che non supera i suoi test), assumono il ruolo. Questo rende le persone responsabili delle conseguenze delle loro azioni in modo molto diretto. E dato che è un lavoro un po 'noioso da fare, li incoraggia a non rompere nuovamente la build.

La persona che è attualmente responsabile della build potrebbe avere un cappello speciale. Potrebbe esserci una cerimonia per consegnarlo.

Si noti che, come afferma Thorbjørn, essere responsabile della build non è lo stesso che essere responsabile del server di build. La responsabilità del server potrebbe rimanere permanentemente con uno o più membri del team inclini a livello infrastrutturale, mentre la responsabilità della build si sposta.

Ora, a parte i dettagli del processo, mi unirò al coro di persone che esprimono sgomento per gli sviluppatori che effettuano il check-in senza aver eseguito build e test. Inaccettabile!

Se hai alcuni membri del team che hanno maggiori probabilità di infrangere la build (e sulla base della mia esperienza, sto pensando principalmente ai membri di un altro paese) e se stai usando un bel controllo moderno della fonte come Mercurial o Git, potresti farli fare il check-in in un ramo diverso dal resto del team, eseguire un processo CI separato su quello e unire automaticamente le modifiche da quel ramo al trunk dopo una compilazione riuscita (nota che dovresti eseguire una seconda build e test dopo l'unione prima di controllare l'unione!). Poiché la fusione automatica non ha sempre successo, ciò alla fine lascerebbe il ramo che richiede attenzione manuale, il che potrebbe essere un vero dolore. Potrebbe essere meno doloroso che avere il codice rotto verificato per il resto della squadra, però.

Come diceva Jonathan Khoo, dovreste essere tutti responsabili del server di compilazione e dello script di compilazione. Ci sono tre ragioni:

1. Al momento hai il caso di un "Bus 1", il che significa che se sei investito da un bus, l'intera conoscenza del server di build e degli script di build andrà persa.
2. Gli script che sono stati scritti (nel modo giusto o sbagliato) da te hanno avuto solo il tuo contributo. Proprio come qualsiasi codice, più persone sono coinvolte più ampia è la base di conoscenza che può essere applicata ad essa.
3. Alla fine, quando qualcosa va storto, senti solo il dolore. Il dolore è una buona cosa ma non quando è isolato. Al momento hai a che fare con il dolore, ma se tutti gli altri avessero avuto il dolore, scopriresti che alla fine sarebbero più severi nel testare il codice prima di impegnarsi.

Sono molto coinvolto con CI stesso e cado nella trappola di essere quello che mantiene gli script, ma qui ci sono un paio di cose che puoi fare per mitigarlo.

1. Gli script di compilazione non devono essere eseguiti solo sui server CI, ma anche su macchine di sviluppo locale. Dovrebbero produrre gli stessi risultati, eseguire gli stessi test e fallire per gli stessi motivi. Ciò consente agli sviluppatori di eseguire lo script prima di eseguire il commit del proprio codice.
2. Se qualcuno rompe la build, rendila pubblica tramite l'uso di popup sulla barra delle applicazioni, e-mail, luci lampeggianti, rumori ecc. Serve non solo a mettere in imbarazzo i membri del team, ma offre l'opportunità a tutti gli altri membri del team di saltare e assistere.
3. Per un po 'evitare di correggere la build. Chiedi a qualcun altro di farlo. Se nessun altro salta in alto, aspetta che accadano cose brutte e usalo come punto di apprendimento per l'intero team per capire perché il server CI è importante.
4. Cerca di mantenere il tuo server di build e le macchine di sviluppo il più possibile privi dei componenti di terze parti installati, in particolare mantenendo pulito il GAC. Affidati a componenti di terze parti che si trovano nella cartella della libreria dei progetti. Ciò consente di identificare i componenti mancanti più rapidamente.

La visibilità ti aiuterà. Tutti i membri del team devono sapere che esiste un problema attivo che dovrebbero risolvere. Le notifiche e-mail sono utili, ma se uno sviluppatore è occupato e non reagisce immediatamente, probabilmente se ne dimenticherà e l'e-mail finirà in un enorme mucchio di notifiche.

Puoi provare a utilizzare strumenti come Catlight o BuildNotify . Mostrano lo stato corrente delle build importanti nell'area del vassoio. Ogni volta che lo sviluppatore guarda l'orologio vedrà che c'è un build rotto che deve essere riparato.

Catlight mostrerà anche chi ha rotto per primo la build, esercitando una pressione sociale su questa persona, poiché l'intera squadra la vedrà ad ogni fallimento della build consecutiva.

Una strategia è quella di utilizzare molte piccole filiali per molti piccoli progetti. Quindi, quando qualcuno rompe la build, sta solo rompendo la build per se stesso. Quindi ricevono l'email infastidita dal server di build e spetta a loro preoccuparsene.

Un altro è migliorare il livello di responsabilità delle persone. Ad esempio, se usi qualcosa come Rietveld, le persone non possono impegnarsi senza passare la revisione tra pari. (Il processo in pratica è molto più leggero di quanto si pensi. Ma costringe le persone a "pipeline" e lavorare su più cose contemporaneamente. Preservare la build è responsabilità sia del committer che dei revisori. Se qualcuno interrompe regolarmente la build o approva le cose che la interrompono, allora non lasciare che forniscano le approvazioni finali per gli commit. Combina con un processo in cui chiunque può facilmente ripristinare qualsiasi modifica e la build non si interromperà spesso e non rimarrà interrotta una volta apportata la modifica.

Ho intenzione di rompere con il coro qui, e dire che in realtà, rompere la build di tanto in tanto non è una cosa così brutta, in quanto mostra che il vero lavoro è stato fatto. Sì, gli sviluppatori dovrebbero creare e testare prima di impegnarsi, ma l'onere principale dei test dovrebbe essere sostenuto dagli strumenti di automazione dello sviluppo, incluso il server di integrazione continua. Gli strumenti sono lì per essere utilizzati e, a meno che la build non si interrompa di tanto in tanto, non è chiaro che stai spingendo il più forte possibile. Ritengo, tuttavia, che la build non dovrebbe mai rimanere interrotta per un periodo di tempo significativo e favorirebbe persino il rollback automatico o un processo di commit in più fasi se ciò aiuta a supportare gli obiettivi gemelli di feedback rapido da strutture di test centralizzate e automatizzate, più un tronco "verde".

Coppie da tenere a mente:

1. Il tuo team ha bisogno di un insieme di standard da seguire
2. È necessario ottenere la gestione a bordo con l'idea di codice pulito e lottare per migliorare le pratiche del codice.
3. Test test test! Testare sempre prima del check-in.
4. Anche se concordo sul fatto che è ok interrompere la build, è un'occasione rara e intendo estremamente rara che sarebbe accettabile. Se questo è quotidiano, cercherei la porta o parlerei con il mio capo degli standard.

Nel complesso, voi ragazzi dovete stabilire, scrivere standard basati sulle migliori pratiche e non sulle vostre pratiche individualmente (ovviamente quelle non stanno funzionando). Una volta che tutti sono d'accordo sugli standard, avviare il processo di revisione del codice e applicare gli standard. Sembra quasi che la direzione sia andata in vacanza e non sia più tornata. Queste sono cose che onestamente sono piuttosto basilari per qualsiasi negozio. la base del buon codice inizia con buoni standard per dettare il codice del team e come è scritto. Solo i miei pensieri. Di recente sono entrato in una situazione simile nel mio nuovo lavoro e ho parlato con il mio capo. Gli ha spiegato che abbiamo bisogno che XYZ sia completato perché influenza ABC. Due settimane dopo ho scritto un elenco di standard di codice da seguire e l'ho presentato. Seguito dai miei collaboratori che ci davano un contributo e circa 2 mesi dopo avevamo messo in atto degli standard che risolvevano tonnellate di problemi.