Baby sitter il tuo sistema di integrazione continua

Prima di tutto: ogni persona è responsabile del processo di creazione . Sembra che i membri della tua squadra non siano maturi ... Nessuno riesce a scrivere codice e farselo dare al server CI sperando che funzioni. Prima di eseguire il codice, è necessario testarlo sul proprio computer locale. Dovresti essere sicuro che il codice che stai registrando non romperà la build. Naturalmente, ci sono casi in cui la generazione si interrompe involontariamente (ad es. Se un file di configurazione è stato modificato o il commit è stato eseguito inavvertitamente).

La maggior parte dei server CI (ho usato solo Hudson) invierà un'email automatica con i dettagli dei commit effettuati che hanno causato la rottura della build. L'unica parte del tuo ruolo è quella di stare dietro di loro con un'aria dura fino a quando il sospettato risolve qualsiasi cosa abbia rotto.

La tua squadra ha sbagliato una cosa:

Essere responsabile per il server di costruzione non è lo stesso di essere responsabile per build .

È responsabilità della persona che controlla il codice per farlo funzionare (per un certo valore del lavoro). L'unico motivo per avere un server di build è quello di catturare le sviste in questo processo. Qualsiasi server di build che valga la pena, può avvisare la / le persona / e che ha effettuato il check-in del codice dall'ultima build (così come chiunque altro sia interessato) con le seguenti informazioni:

• Costruisci rotto!
• Cosa non ha funzionato durante la costruzione!
• Cosa è cambiato dall'ultima build!

Molto spesso accade per email. È importante che ciò avvenga abbastanza rapidamente dopo ogni check-in.

La persona può quindi vedere cosa è andato storto e correggerlo, quindi il server di build avvisa chiunque sia interessato a ripristinare la build alla normalità. Questo dovrebbe accadere tutto da solo senza alcun coinvolgimento di 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 "strane condizioni esistenti" si verificano molto frequentemente, scopri cosa lo causa e rendi il sistema più solido.

Cambia il processo. Se un commit interrompe la compilazione, esegue automaticamente il rollback del commit e avvisa lo sviluppatore che lo ha interrotto. È sciocco permettere un errore da parte di un membro del team di rallentare il resto della squadra. Oppure, invece di fare eseguire automaticamente le build di integrazione, chiedere agli sviluppatori di verificare il computer di integrazione e, se la compilazione ha esito positivo, possono eseguire il commit. L'integrazione continua non significa "controlla in quale roba ti piace e qualcuno la risolverà per te".

La strategia "golden branch" non funziona a meno che non ci sia un gatekeeper per il ramo d'oro.

Un DVCS come Git potrebbe aiutare; invece di impegnarsi, 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 abbia esattamente gli stessi passi di una build CI. Cioè, il server CI è configurato per includere passaggi aggiuntivi come test di unità / integrazione, copertura, ecc. Che non possono essere eseguiti localmente. Inevitabilmente, gli sviluppatori verranno morsi da uno dei passaggi che non possono eseguire localmente e cominceranno a chiedersi perché si preoccupino di creare una versione locale prima del check-in.

Mantengo la mia intera build autosufficiente e il server CI semplicemente avvia una build di rilascio senza alcuna configurazione / procedura estranei definiti. Gli sviluppatori possono eseguire una versione di build a livello locale prima del check-in che include tutti i passaggi che verranno eseguiti dalla build di elementi della configurazione ed essere molto più sicuri che nulla si interromperà quando fanno il check-in.

I vantaggi aggiunti a questo approccio includono:

• è facile passare da un server CI all'altra perché non hai investito un po 'di tempo nella configurazione di passaggi estranei
• tutti gli strumenti di generazione sono sotto controllo del codice sorgente, il che significa che tutti gli sviluppatori utilizzano 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 è ridicolo, ma altri lo hanno coperto.

Prima di tutto, gli sviluppatori non dovrebbero interrompere le build regolarmente - dovrebbero costruire e eseguire i test localmente prima di impegnarsi nel ramo CI. Dovrebbe essere un segno di vergogna per rompere la build, ed è importante farlo rispettare. L'ho fatto pubblicando statistiche e ho visto altre squadre avere una "build bag" in cui si inserisce un dollaro ogni volta che si rompe la build. Alla fine del progetto, i soldi vanno alla birra.

Se la vergogna / l'orgoglio personale non funzionano, potrebbe essere necessario passare a cose più pesanti (ad es. terminazione minacciosa). Rompere la costruzione prima di partire per la giornata dovrebbe essere un grave reato. E ogni sviluppatore dovrebbe avere una notifica di stato sul proprio desktop. La parte migliore di tutto questo è che incoraggia i commit più piccoli, che sono comunque preferiti.

Detto questo, a volte la build si spezzerà (ragioni di configurazione CI, ad esempio). E a volte le persone si rovinano e vanno via per la giornata con la costruzione rotta. Questo è il motivo per cui dovresti mirare a un processo che permetta di ottenere velocemente e facilmente dei rollback su versioni conosciute. Se puoi sempre tornare all'ultima buona build (e avere la versione roll-back distribuita in tutti i posti necessari), allora nello scenario peggiore di una build rotta in cui il colpevole è partito per la sera puoi tirare torna all'ultima buona versione e grida a lui / lei al mattino.

Non posso raccomandare abbastanza Libro di consegna continua . Se stai cercando una guida su come maturare il tuo processo di configurazione, fai una prova.

Ho sentito parlare di una cosa Microsoft (forse?) fare, che è quello di avere il ruolo di costruire babysitter muoversi nel team. Il modo in cui lo fanno è che quando qualcuno interrompe la build (che probabilmente dovrebbe includere il controllo di qualcosa che fallisce nei test), assume il ruolo. Questo rende le persone responsabili delle conseguenze delle loro azioni in modo molto diretto. E dato che è un lavoro un po 'fastidioso da fare, li incoraggia a non rompere di nuovo la build.

La persona che è attualmente responsabile della build potrebbe avere un cappello speciale. Ci potrebbe essere una cerimonia per la consegna.

Si noti che, come dice Thorbjørn, essere responsabile per la build non è la stessa responsabilità del server di build. La responsabilità per il server potrebbe riposare in modo permanente con uno o più membri più inclini alle infrastrutture, mentre la responsabilità per la costruzione si sposta.

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

Se hai alcuni membri del team che hanno maggiori probabilità di rompere la build (e in base alla mia esperienza personale, penso principalmente ai membri di un altro paese), e se stai usando qualche bella fonte moderna controllo come Mercurial o Git, puoi farli controllare in un ramo diverso dal resto del team, eseguire un processo CI separato su quello, e unire automaticamente le modifiche da quel ramo al tronco dopo una build di successo (nota che tu Devo eseguire una seconda build e test dopo l'unione prima di controllare l'unione!). Dal momento che la fusione automatica non ha sempre successo, questo alla fine lascerebbe il ramo che richiede attenzione manuale, tuttavia, il che potrebbe essere un vero dolore. Potrebbe essere meno doloroso di avere il codice rotto registrato per il resto della squadra, però.

Come Jonathan Khoo ha detto che dovresti essere responsabile per il build server e lo script di build. Ci sono tre ragioni:

1. Al momento hai un caso di "Bus di 1", il che significa che se sei stato investito da un bus allora l'intera conoscenza del server di build e degli script di compilazione è persa.
2. Gli script che sono stati scritti (a torto oa ragione) 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. Finalmente quando qualcosa va storto solo tu senti 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 sofferto, scopriresti che alla fine sarebbero stati più severi nel testare il codice prima di impegnarsi.

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

1. Gli script di build non dovrebbero essere eseguiti solo sui server di CI, ma anche su macchine di sviluppo locale. Dovrebbero produrre le stesse uscite, eseguire gli stessi test e fallire per gli stessi motivi. Ciò consente agli sviluppatori di eseguire lo script prima di eseguire il commit del codice.
2. Se qualcuno interrompe la build rendilo pubblico tramite l'uso di popup della task tray, 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 salta su e assisti.
3. Per un po 'evita di correggere la build. Chiedi a qualcun altro di farlo. Se nessun altro salta su aspetta che accadano cose brutte e lo usi come punto di apprendimento per l'intero team per capire perché il server CI è importante.
4. Cerca di mantenere il tuo build server e le macchine di sviluppo prive di componenti di terze parti installate il più possibile, in particolare mantieni il GAC pulito. Affidati a componenti di terze parti nella cartella della biblioteca dei progetti. Questo aiuta a identificare i componenti mancanti più rapidamente.

La visibilità ti aiuterà. Tutti i membri del team devono sapere che c'è un problema attivo da risolvere. Le notifiche via email sono utili, ma se uno sviluppatore è occupato e non reagisce immediatamente, probabilmente lo dimenticherà e l'email 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'è una build rotta che deve essere riparata.

Catlightmostreràanchechiharottolabuildperprimo,esercitandopressionesocialesuquestapersona,poichél'interoteamlavedràinognifallimentodibuildconsecutivo.

Una strategia consiste nell'utilizzare molte piccole filiali per molti piccoli progetti. Poi, quando qualcuno rompe la build, stanno solo rompendo la build per se stessi. 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 utilizzi qualcosa come Rietveld allora le persone non possono eseguire il commit senza passare la peer review. (Il processo in pratica è molto più leggero di quanto tu pensi che sia, ma costringe le persone a "pipeline" ea lavorare su più cose contemporaneamente.) La conservazione della build è responsabilità sia del committer che dei revisori. Se qualcuno interrompe regolarmente la build o approva le cose che interrompono la compilazione, allora non lasciare che forniscano le approvazioni finali per i commit. Combina con un processo in cui chiunque può facilmente eseguire il rollback di qualsiasi modifica e la build non si interromperà più spesso e non rimarrà interrotta una volta apportate le modifiche.

Ho intenzione di rompere con il coro qui, e dire che in realtà, rompere la costruzione di tanto in tanto non è una cosa così brutta, in quanto mostra che si sta facendo un vero lavoro. Sì, gli sviluppatori dovrebbero creare e testare prima di impegnarsi, ma il carico principale dei test dovrebbe essere sostenuto dagli strumenti di automazione dello sviluppo, incluso il server di integrazione continua. Gli strumenti sono lì per essere usati, e a meno che la costruzione non si rompa di tanto in tanto, non è chiaro che tu stia spingendo più strong che puoi. Tuttavia, ritengo che la build non dovrebbe mai rimanere rotta per un periodo di tempo significativo e preferirebbe persino i rollback automatici o un processo di commit a più fasi se questo aiuta a supportare gli obiettivi gemelli del feedback rapido da strutture di test centralizzate e automatizzate, più un tronco "verde".

Cose da tenere in considerazione:

1. Il tuo team ha bisogno di una serie di standard da seguire
2. È necessario coinvolgere il management con l'idea del codice pulito e sforzarsi di migliorare le pratiche del codice.
3. Test test test! Esegui sempre i test prima di effettuare il check-in.
4. Anche se sono d'accordo, è giusto interrompere la costruzione, è un'occasione rara e intesa estremamente rara che sarebbe accettabile. Se questo è quotidiano, cercherò la porta o parlerò con il mio capo degli standard.

Nel complesso, voi ragazzi dovete mettere giù, redigere 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 l'applicazione degli standard. Sembra quasi che la direzione sia andata in vacanza e non sia mai tornata. Queste sono cose che onestamente sono piuttosto semplici per qualsiasi negozio. la base del buon codice inizia con buoni standard per dettare il codice del team e come è stato scritto. Solo i miei pensieri Recentemente sono entrato in una situazione simile al mio nuovo lavoro e ho parlato con il mio capo. Spiegato che abbiamo bisogno che XYZ sia completato perché riguarda l'ABC. Due settimane dopo ho scritto un elenco di standard di codice da seguire e presentato. Seguito dai miei collaboratori che hanno dato il loro contributo e circa 2 mesi dopo, abbiamo adottato standard che risolvono tonnellate di problemi.