A che punto è interessante un server di integrazione continua?

Is it just useful for the speed gain? (not an issue in our case)

Ogni volta che passi il tuo processo in bicicletta è tempo che potresti aver speso per entrare nel flusso dello sviluppo.

Inoltre, risparmierai tempo nelle pietre miliari perché idealmente stai costruendo bit completamente pacchettizzati e pronti per la spedizione che possono essere masterizzati direttamente su CD, caricati sul Web, ecc.

Is it useful because old builds can be recreated? (but we can do this to with Mercurial, by checking out old revs)

No, non si ricreano build. Puoi utilizzare la build creata e mantenerla attiva finché le impostazioni di conservazione non vengono eliminate.

Lo costruisci sul server di build, invece che su una scatola di Dev.

Here we've got about 1500 unit tests and they pass (on old Core 2 Duo workstations) in about 90 seconds (because they're really testing "units" and hence are very fast). The rule we have is that we cannot commit code when a test fail.

Inoltre, non ti piacerebbe essere in grado di eseguire l'integrazione automatizzata o test end-to-end sul tuo codice e catturare problemi che i test unitari non cattureranno?

Non vorrai eseguire quelli su scatole di sviluppo, perché sarebbe un problema impostare e mantenere quell'ambiente. Anche i test di integrazione tendono ad essere molto lenti da eseguire.

at which point is it useful?

È un investimento come qualsiasi altro.

Usalo una volta e potresti uscire alle spalle o solo pareggiare. Usalo su più progetti e probabilmente verrai fuori prima.

Dipende anche dal tipo di applicazioni che fai.

Se si realizzano applicazioni Web che devono essere distribuite su un Java Application Server o IIS, l'IC diventa un gioco da ragazzi. Lo stesso se hai un database come parte del tuo progetto. La distribuzione è dolorosa da eseguire manualmente e il tuo team addetto al QA (se ne hai uno) ne avrà bisogno ogni tanto a un giorno.

Inoltre, potresti voler vedere come le tue esigenze e i tuoi problemi sono in linea con Il codice di 12 passaggi per migliorare di Joel Spolsky . In particolare 2, 3 e 10 (anche se sono tutti interessanti e importanti).

At which point is it useful?

• Il tuo ciclo di build + test dura più di un paio di minuti. Con 5 minuti di test non dovrai più eseguire autonomamente tutti i test, specialmente per piccole modifiche.
• Inizi a creare più varianti. Se hai un paio di clienti con diverse personalizzazioni, dovresti eseguire i test su ciascuna variante, quindi la quantità di lavoro inizierà a crescere abbastanza velocemente. Quindi eseguirai la suite di test per una variante sul computer dello sviluppatore e lascialo a CI per eseguirlo sul resto.
• Si scrivono test di integrazione automatici che richiedono una configurazione dell'ambiente di test non banale. Di quanto si desidera testare un ambiente di test canonico, dal momento che gli sviluppatori possono avere il loro ambiente modificato in vari modi a causa delle modifiche allo sviluppo. L'IC è il posto più adatto per l'ambiente canonico.
• I tester possono semplicemente estrarre l'ultima build da CI. Quindi non hanno né bisogno di avere, imparare e usare gli strumenti di sviluppo, né alcuno sviluppatore deve inviarli manualmente la loro compilazione.
• Quando ti stai preparando per il rilascio:
  • I test diventano più importanti, quindi avere un posto con build preparate per il test è ancora più utile.
  • Si è certi che tutte le build sono costruite con lo stesso ambiente di build, quindi si evitano problemi che potrebbero essere introdotti da sottili differenze tra le installazioni dello sviluppatore.
  • Si è certi che si sta costruendo esattamente ciò che viene controllato nel sistema di controllo della versione. Durante lo sviluppo se qualcuno si dimentica di controllare qualcosa, lo troverai abbastanza rapidamente, perché fallirà per il prossimo sviluppatore. Ma se tale build è passata al QA o alla produzione e riportano un bug, sarebbe molto difficile rintracciare.

Probabilmente non hai ancora bisogno di CI, ma penso che diventerà utile quando arriverai alla fase di test. Jenkins viene installato in poche ore e semplifica i tuoi test e aiuta a evitare errori stupidi (che si verificano soprattutto quando affronti una correzione rapida alla produzione).

Per me un C diventa interessante se la tua squadra ha più di 1 membro.

Devi smettere di pensare a CI come "un altro PC che esegue i test per me". Elementi di configurazione relativi al processo di generazione e alla gestione del rilascio definiti e automatici .

CI è l'unica entità autorevole che crea la tua versione del software. Se non si basa sull'elemento della configurazione, non è successo.

Con un elemento di configurazione hai le restrizioni per automatizzare tutto ciò che ti mostrerà tutte le modifiche manuali, gli hack e le scorciatoie che hai a disposizione e semplicemente non funzionano con un elemento della configurazione e dovrebbero essere evitati in primo luogo.

Problemi che evita:

• Chi è responsabile della creazione del rilascio
• Questa persona è disponibile 24 ore su 24, 7 giorni su 7
• Ma si basa sulla sindrome della mia macchina
• Rimuove tutte le ambiguità riguardo a quale versione è stata rilasciata

Vantaggi (troppi per citarli tutti):

• Numerazione automatica della versione
• Integrazione del rilevamento dei problemi
• Generazione metrica automatica
• Analisi del codice statico
• Implementazione automatizzata
• Impostazioni multistadio

C'è un problema fondamentale di Continuous Integration (CI) perfettamente rispecchiato nella tua domanda: le pratiche di CI sono difficili da implementare e difendere perché il software del server CI non è banale da configurare, né è banale far funzionare i tuoi progetti attraverso un server CI. Con questo, diventa difficile vedere realmente dov'è il vantaggio nell'abbracciare l'IC.

Prima di tutto, la CI riguarda l'intuizione e la qualità. Una buona IC ti avvicina al tuo progetto, ti dà un feedback adeguato su parametri di qualità, documentazione, conformità agli standard di codifica, ecc. Dovrebbe fornirti gli strumenti per visualizzare facilmente tutto questo e permetterti di riconoscere a colpo d'occhio e facilmente associare un insieme di modifiche con un'istantanea specifica di tutte queste metriche del progetto.

È non solo per eseguire i test unitari. Affatto! Il che mi porta alla qualità. CI abbraccia gli errori, non li evita o li butta via. Quello che fa è semplicemente fornire uno strumento per l'errore all'inizio, piuttosto che in seguito. Quindi non si commette realmente codice precedentemente testato su un server CI. Sebbene sia necessario eseguire il commit di codice pulito e non danneggiato, in realtà si utilizza il server CI per eseguire automaticamente un generatore di integrazione automaticamente tramite il codice e valutare se tutto è venuto fuori correttamente. Se è così, pulito! In caso contrario, nessun problema: le buone pratiche informatiche stabiliscono che la tua prossima priorità dovrebbe essere quella di correggere ciò che si è rotto. Che, in un buon server CI, dovrebbe essere facilmente segnalato per te.

Con l'aumentare delle dimensioni della squadra, l'integrazione del codice di tutti diventa naturalmente più difficile. Dovrebbe essere compito di un server CI centralizzato testare tutte le parti integrate e sottrarre tale onere ai membri del team. Quindi è necessario che tutti facciano il commit in anticipo (e nel modo più pulito possibile) e quindi monitorino lo stato delle build (di solito sono coinvolte le notifiche). E ancora, se qualcosa si rompe a causa dell'impegno di alcuni sviluppatori, immediatamente diventa la sua responsabilità nel correggerlo e riportare immediatamente le build automatiche nello stato OK.

Quindi, a mio avviso, ogni singolo progetto trae vantaggio dall'essere continuamente integrato. Il fatto è che fino ad ora, a causa della complessità da capogiro di ogni singolo server CI che conosco, le persone hanno davvero respinto le pratiche di CI su progetti più piccoli / più semplici. Perché, dai, le persone hanno cose migliori da fare che passare giorni a configurare un software brutto, eccessivamente complesso, sotto carico e gonfio.

Ho avuto lo stesso identico problema, ed è quello che mi ha fatto sviluppare Cintient nel mio tempo libero da circa un anno fa. La mia premessa consisteva nel semplificare l'installazione, la configurazione e l'uso e nel far sì che venissero trasmessi su quei parametri di qualità che praticamente tutti gli altri falliscono o sono insufficienti. Quindi, dopo questa lunga risposta arriva il mio spudorato plug di puntare il link GitHub per il progetto (che è gratuito e open-source, natch). Ha anche alcuni screenshot, apparentemente. :-) link

Spero di averti aiutato.

(NOTA: modificato dopo il commento di Bryan Oakley, sul fatto che avrei dovuto impiegare più tempo per costruire una risposta migliore. Penso anche che avesse ragione.)