Integrazione continua: quale frequenza?

Ho sempre lanciato build dopo ogni commit, ma su questo nuovo progetto, gli architetti mi hanno appena chiesto di cambiare la frequenza in "una build ogni 15 minuti", e non riesco proprio a capire perché sarebbe una buona ragione contro " basandosi su ogni commit ".

Prima di tutto, alcuni dettagli:

• Progetto Objective-C (iOS 5)
• 10 sviluppatori
• ogni build richiede in realtà ~ 1 minuto e include test di build e unità.
• il server di integrazione è un Mac Mini, quindi la potenza di elaborazione non è davvero un problema qui
  • usiamo Jenkins con il plugin XCode

Le mie argomentazioni erano che se costruisci ad ogni commit, puoi vedere subito cosa è andato storto e correggere direttamente i tuoi errori, senza disturbare troppo gli altri sviluppatori. Inoltre il nostro tester è meno infastidito dagli errori UT in questo modo. Le sue argomentazioni erano che gli sviluppatori saranno inondati da messaggi di "errore di compilazione" (che non è del tutto vero, poiché Jenkins può essere configurato per inviare una posta solo per la prima build non funzionante) e che le metriche non possono essere eseguite correttamente se la frequenza di build è troppo alto.

Allora, qual è la tua opinione su questo?

Fallire velocemente è un buon principio: prima sai che la build è rotta, prima si può identificare il commit offensivo e la build è riparata.

Costruire su ogni commit è la cosa giusta da fare.

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

Se la build si interrompe così spesso da costituire un problema, rispondi per rieducare il team sull'importanza di non interrompere la build e in tecniche che garantiscano che ciò non accada (recuperi frequenti, checkin dance, compilazione ed esecuzione di unit test localmente ecc ...).

Non ha letteralmente senso fare una build ogni 15 minuti se nulla è cambiato. Ma allo stesso modo non ci sono aspetti negativi, a proposito, Jenkins invierà solo e-mail in caso di fallimento e quindi di successo e non tutto il resto (es. 10 fallimenti).

Lo facciamo ad ogni commit. Tuttavia eseguiamo il polling del repository ogni quindici minuti e controlliamo eventuali cambiamenti, forse è quello a cui si riferiscono i colleghi.

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

E 'intenzione di sviluppatori di piena con la posta di più se è solo ogni 15 minuti. Questo perché non si saprà per certo chi ha rotto la build e quindi spedire più persone.

Per quanto riguarda le metriche, se è davvero un problema, cosa che non posso dire perché non so con quali metriche ritengono che ci sia un problema, puoi sempre fare un altro lavoro per raccogliere le metriche.

Forse il requisito deve essere "costruito al massimo una volta ogni 15 minuti". Ciò potrebbe avere senso per i progetti con attività di commit molto frequenti (ovvero commit multipli in pochi minuti) e forse tempi di costruzione lunghi. Naturalmente dipende anche da come vengono utilizzate le build. Per i tester potrebbe essere un po 'confuso ottenere più build in 15 minuti ...

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

Alcuni sviluppatori vogliono essere autorizzati a eseguire i commit in un modo in cui i file appartenenti a una modifica funzionale non sono impegnati in una singola procedura atomica. Sono necessari due o tre minuti per eseguire 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, senza utilizzare un DVCS.

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

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

Anche se Jenkins è configurato per basarsi su un commit del controllo del codice sorgente su un progetto o su una delle sue dipendenze, ciò non impedisce a uno sviluppatore di eseguire la distribuzione nel repository di artefatti senza impegnarsi prima nel controllo del codice sorgente. Se distribuiscono una modifica API non coordinata o un bug in una dipendenza dal repository di artefatti, questo può interrompere la compilazione senza avviare il lavoro Jenkins. Personalmente vorrei sapere questo al più presto.

Idealmente, dovresti compilare per ogni commit e anche su un programma per verificare le situazioni come ho appena descritto. Ciò significherebbe concettualmente che costruisci almeno una volta ogni 15 minuti .

Se hai i tuoi lavori Jenkins impostati per essere eseguiti su distribuzioni di artefatti di dipendenza (e se lo fai ... Bravo), puoi prob ascia la build pianificata se i tuoi test di unità sono solidi (nel senso che non testano le dipendenze) e il tuo i test di integrazione / funzionali non fanno parte del lavoro di Jenkins.

Per quanto riguarda il problema del "diluvio di e-mail", dico che essere invaso da e-mail su una build non funzionante è una buona cosa. Assicurati di forzare gli sviluppatori a rispondere all'e-mail con una descrizione e vedrai che le tue creazioni rotte diminuiranno, fidati di me.

Hai detto che non riesci a capire il loro ragionamento, quindi devi chiederglielo. Non solo indovinare ciò che vogliono e cercare di implementarlo, e certamente non solo implementare ciò che hanno chiesto senza capire perché lo hanno chiesto.

Detto questo, per rispondere alla domanda generale, dipende dalla filosofia di sviluppo che usi. Se si prevede che ogni commit funzioni, è necessario testare ogni commit. Se usi un DVCS con la filosofia secondo cui ogni push dovrebbe funzionare, allora testa ogni push.

In generale, è meglio dire alle persone qualcosa che non conoscono, quindi ripetere ciò che sanno. Ad esempio, se vogliono ridurre il numero di e-mail ridondanti che ricevono, modifica le impostazioni e-mail, non la frequenza di creazione.