Integrazione continua: quale frequenza?

Fail fast è un buon principio - prima si sa che la build è rotta, prima si può identificare il commit incriminato e la build risolta.

Costruire su ogni commit è la cosa giusta da fare.

Costruire ogni 15 minuti può essere inutile se il progetto ha un volume elevato di commit entro un simile lasso di tempo - rintracciare il commit errato richiederebbe più tempo e potrebbe essere difficile da determinare (potrebbe anche esserci in una situazione in cui più commit hanno cose diverse che interrompono la build). C'è anche la possibilità che in tempi tranquilli (notte?) Si finisca per ricostruire anche se non sono state apportate modifiche.

Se la build si rompe così spesso che si tratta di un problema, la risposta è di rieducare il team sull'importanza di non rompere la build e nelle tecniche che assicurano che ciò non accada (frequenti recuperi, check-in, compilazione e eseguire unit test localmente ecc ...).

Non c'è letteralmente alcun punto nel fare una build ogni 15 minuti se non è cambiato nulla. Ma allo stesso modo non c'è un rovescio della medaglia, afaik, jenkins invierà solo e-mail in caso di insuccesso e quindi di successo e non di tutto ciò che è in mezzo (es. 10 fallimenti).

Lo facciamo su ogni commit. Tuttavia, eseguiamo il polling del repository ogni quindici minuti e controlliamo le modifiche, forse questo è ciò a cui i colleghi si riferiscono.

Ti aspetti che i tuoi 10 sviluppatori si impegnino più di una volta ogni quindici minuti? Sembra piuttosto una stima elevata. 10 dev's significa che dopo ogni 150 minuti la stessa persona si sta impegnando di nuovo, quindi sono 2,5 ore. Quindi nel tuo giorno medio ogni dev commette 3 volte. Personalmente faccio un commit ~ 2 giorni ... a volte più a volte meno.

Riempirà gli sviluppatori di mail more se è solo ogni 15 minuti. Questo perché non saprà per certo chi ha rotto la build e quindi invia più persone.

Per quanto riguarda le metriche, se è davvero un problema - che non posso dire perché non conosco le metriche secondo le quali c'è un problema-, puoi sempre fare un altro lavoro per raccogliere le metriche.

Forse il requisito dovrebbe essere "build al massimo una volta ogni 15 minuti". Questo potrebbe avere senso per i progetti con attività di commit molto frequenti (vale a dire più commit in pochi minuti) e forse lunghi tempi di costruzione. Ovviamente dipende anche da come vengono utilizzate le build. Per i tester potrebbe essere un po 'di confusione ottenere più build entro 15 minuti ...

Ma sono d'accordo sul fatto che non ha senso costruire se nulla è cambiato.

Alcuni sviluppatori vogliono essere autorizzati a fare commit in un modo in cui i file appartenenti a una modifica funzionale non sono impegnati in un'unica procedura atomica. Hanno bisogno di due o tre minuti per fare un "commit logico", che consiste in alcuni "commit fisici". Questo è in genere il caso in cui gli sviluppatori si impegnano direttamente in un repository centrale, non utilizzando un DVCS.

In questi casi, potrebbe essere una buona idea lasciare che il tuo server CI attenda qualche tempo dopo l'ultimo commit prima di iniziare una nuova build. Ma 15 minuti sembrano essere un numero molto alto, dovrebbero bastare 5 minuti o meno.

Oppure, meglio (!), prova a guidare i tuoi sviluppatori a lavorare solo in piccole parti, solo una cosa alla volta, rendendo molto più facile eseguire solo commit fisici "funzionali completi". Quindi una build dopo ogni commit funzionerà senza problemi.

Anche se hai impostato Jenkins per costruire su un controllo del codice sorgente di commit su un progetto o su una delle sue dipendenze, questo non impedisce a uno sviluppatore di eseguire la distribuzione nel repository di risorse senza prima eseguire il commit del controllo del codice sorgente. Se distribuiscono una modifica API non coordinata o un bug in una dipendenza dal repository di risorse, ciò può interrompere la build senza attivare il lavoro di Jenkins. Io personalmente vorrei sapere di questo al più presto.

Idealmente si dovrebbe costruire per ogni commit e anche su un programma per verificare le situazioni come ho appena descritto. Ciò significherebbe concettualmente costruire almeno una volta ogni 15 minuti .

Se hai i tuoi lavori Jenkins impostati per l'esecuzione su distribuzioni di artefatti di dipendenza (e se lo fai ... Bravo), puoi verificare la build pianificata se i tuoi test di unità sono solidi (il che significa che non testano le dipendenze ) e i test di integrazione / funzionali non fanno parte del lavoro di Jenkins.

Per quanto riguarda il problema del "flood with email", dico che essere inondato di email su una build rotta è una buona cosa. Assicurati di obbligare gli sviluppatori a rispondere all'e-mail con una descrizione e vedrai che le tue costruzioni rotte sono al minimo, fidati.

Hai detto che non puoi capire il loro ragionamento, quindi devi chiedere loro. Non solo indovinare ciò che vogliono e provare a implementarlo, e certamente non implementare solo ciò che hanno chiesto senza capire perché lo hanno richiesto.

Detto questo, per rispondere alla domanda generale, dipende dalla filosofia di sviluppo che usi. Se ogni commit dovrebbe funzionare, allora ogni commit dovrebbe essere testato. Se utilizzi un DVCS con la filosofia che ogni push dovrebbe funzionare, prova ogni push.

In generale, è meglio dire alla gente qualcosa che non sanno, quindi ripetere ciò che sanno. Ad esempio, se vogliono ridurre il numero di e-mail ridondanti ricevute, ritoccare le impostazioni e-mail, non la frequenza di compilazione.