A che punto è interessante un server di integrazione continua?

Ho letto qualcosa sui server CI come Jenkins e mi chiedo: a che punto è utile?

Perché sicuramente per un piccolo progetto in cui avresti avuto solo 5 classi e 10 test unitari, non c'è davvero bisogno.

Qui abbiamo circa 1500 unit test e passano (su vecchie workstation Core 2 Duo) in circa 90 secondi (perché stanno davvero testando "unit" e quindi sono molto veloci). La regola che abbiamo è che non possiamo eseguire il commit del codice quando un test fallisce.

Quindi ogni sviluppatore avvia tutti i suoi test per prevenire la regressione.

Ovviamente, poiché tutti gli sviluppatori lanciano sempre tutto il test, rileviamo errori dovuti a cambiamenti in conflitto non appena uno sviluppatore ne tira il resto (quando presente).

Non è ancora molto chiaro per me: devo installare un server CI come Jenkins? Cosa porterebbe?

È utile solo per il guadagno di velocità? (non è un problema nel nostro caso)

È utile perché è possibile ricreare vecchie build? (ma possiamo farlo con Mercurial, controllando i vecchi regimi)

Fondamentalmente capisco che può essere utile, ma non riesco a capire esattamente perché.

Qualsiasi spiegazione che tenga conto dei punti che ho sollevato sopra sarebbe molto gradita.

È utile solo per il guadagno di velocità? (non è un problema nel nostro caso)

Ogni tempo trascorso in bicicletta per il tuo processo è il tempo che avresti potuto impiegare per entrare nel flusso dello sviluppo.

Risparmierai anche tempo alle pietre miliari perché idealmente stai costruendo bit completamente confezionati e pronti per la spedizione che possono essere masterizzati direttamente su CD, caricati sul web, ecc.

È utile perché è possibile ricreare vecchie build? (ma possiamo farlo con Mercurial, controllando i vecchi regimi)

No, non ricreare build. Usi la build che ha creato e tienilo in giro fino a quando le impostazioni di conservazione non lo eliminano.

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

Qui abbiamo circa 1500 unit test e passano (su vecchie workstation Core 2 Duo) in circa 90 secondi (perché stanno davvero testando "unit" e quindi sono molto veloci). La regola che abbiamo è che non possiamo eseguire il commit del codice quando un test fallisce.

Inoltre, non ti piacerebbe poter eseguire l'integrazione automatizzata o test end-to-end sul tuo codice e rilevare i problemi che i test unitari non rileveranno?

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

a che punto è utile?

È un investimento come un altro.

Usalo una volta e potresti venire fuori o solo in pareggio. Usalo su più progetti e probabilmente uscirai in anticipo.

Dipende anche dal tipo di applicazioni che fai.

Se si creano applicazioni Web che devono essere distribuite su un Java Application Server o IIS, CI 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 controllo qualità (se ne hai uno) ne avrà bisogno ogni giorno come ogni giorno.

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

A che punto è utile?

• Il tuo ciclo build + test dura un paio di minuti. Con un test di 5 minuti non vorrai più eseguire tutti i test da solo, specialmente per piccole modifiche.
• Inizi a creare più varianti. Se hai un paio di clienti con personalizzazioni diverse, dovresti eseguire i test su ogni variante, quindi la quantità di lavoro inizierà a crescere abbastanza velocemente. Quindi eseguiresti la suite di test per una variante sul computer dello sviluppatore e la lasceresti a CI per eseguirla sul resto.
• Scrivi test di integrazione automatizzati che richiedono una configurazione dell'ambiente di test non banale. Di quello che vuoi testare contro un ambiente di test canonico, dal momento che gli sviluppatori possono avere il loro ambiente modificato in vari modi a causa dei cambiamenti di sviluppo. L'IC è il luogo più adatto per l'ambiente canonico.
• I tester possono semplicemente estrarre l'ultima build da CI. Pertanto, non devono né avere, apprendere e utilizzare gli strumenti di sviluppo né gli sviluppatori devono inviare loro la loro build manualmente.
• Quando ti stai preparando per il rilascio:
  • I test diventano più importanti, quindi avere un posto con build preparate per i test è ancora più utile.
  • Sei sicuro che tutte le build siano costruite con lo stesso ambiente di build, quindi eviti i problemi che possono essere introdotti da sottili differenze tra le installazioni degli sviluppatori.
  • Sei certo di creare esattamente ciò che viene verificato nel sistema di controllo della versione. Durante lo sviluppo, se qualcuno dimentica di controllare qualcosa, lo troverai abbastanza rapidamente, perché fallirà per il prossimo sviluppatore. Ma se tale build passasse al QA o alla produzione e segnalassero un bug, sarebbe molto difficile rintracciarlo.

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

Per me un CI 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". CI sull'avere un processo di compilazione e gestione delle versioni definito e automatizzato .

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

Con un elemento della configurazione hai delle restrizioni per automatizzare tutto ciò che ti mostrerà tutte le modifiche manuali, gli hack e le scorciatoie che hai in atto e che 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/7?
• Ma si basa sulla mia sindrome della macchina
• Elimina ogni ambiguità su quale fosse la versione che abbiamo rilasciato

Vantaggi (troppi per menzionarli tutti):

• Numerazione automatica delle versioni
• Integrazione del rilevamento dei problemi
• Generazione metrica automatizzata
• Analisi del codice statico
• Distribuzione automatizzata
• Configurazioni multistadio

C'è un problema fondamentale sull'integrazione continua (CI) che si rispecchia perfettamente nella tua domanda: le pratiche CI sono difficili da implementare e difendere perché il software del server CI non è banale da installare, né è banale mettere i tuoi progetti in esecuzione attraverso un CI server. Con questo, diventa difficile vedere davvero qual è il vantaggio nell'abbracciare CI.

Prima di tutto, CI si occupa di intuizione e qualità. Un buon CI ti avvicina al tuo progetto, ti dà un feedback adeguato su metriche di qualità, documentazione, conformità agli standard di codifica, ecc. Dovrebbe fornirti gli strumenti per visualizzare facilmente tutto questo e permetterti di riconoscere immediatamente e facilmente associare una serie di modifiche a un'istantanea specifica di tutte queste metriche del progetto.

Si tratta non solo di eseguire i test di unità. Affatto! Il che mi porta alla qualità. CI comprende errori, non li evita o li butta via. Quello che fa è semplicemente fornirti uno strumento per errori in anticipo, invece che in seguito. In questo modo non esegui davvero il commit di codice precedentemente testato su un server CI. Anche se dovresti sforzarti di commettere codice pulito e non rotto, in realtà usi il server CI per eseguire automaticamente un builder di integrazione automaticamente attraverso il tuo codice e farlo valutare se tutto è andato bene. Se è così, pulito! In caso contrario, nessun problema: le buone pratiche di CI affermano che la tua prossima priorità dovrebbe essere solo quella di riparare qualunque cosa si sia rotta. Che, in un buon server CI, dovrebbe essere facilmente indicato per te.

All'aumentare delle dimensioni di una 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 rimuovere tale onere dai membri del team. Quindi devi fare in modo che tutti si impegnino presto (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 del commit di alcuni sviluppatori, diventa immediatamente sua responsabilità ripararlo e riportare immediatamente quei build automatici allo stato OK.

Quindi, secondo me, ogni singolo progetto trae vantaggio dall'essere continuamente integrato. Il fatto è che fino ad ora, a causa della complessità sbalorditiva di ogni singolo server CI che conosco, le persone hanno davvero respinto le pratiche 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, poco efficiente 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 era di rendere semplice l'installazione, la configurazione e l'uso e di far sì che fornisse quelle metriche di qualità che praticamente tutti gli altri falliscono o perdono. Quindi, dopo questa lunga risposta arriva la mia spudorata presa di puntamento del collegamento GitHub per il progetto (che è gratuito e open-source, natch). Presenta anche alcuni screenshot, a quanto pare. :-) https://github.com/matamouros/cintient

Spero di averti aiutato.

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