L'integrazione continua è importante per uno sviluppatore solista?

Question

Non ho mai usato strumenti di CI prima, ma da quello che ho letto, non sono sicuro che fornirebbe alcun vantaggio a uno sviluppatore solista che non scrive codice ogni giorno.

Primo: quali vantaggi offre CI a qualsiasi progetto?

Secondo: chi dovrebbe usare CI? Va a vantaggio di tutti gli sviluppatori?

Answer 1

Il concetto di base di CI è che hai un sistema che costruisce il codice ed esegue test automatici ogni volta che qualcuno si impegna nel sistema di controllo della versione. Questi test includeranno test unitari e funzionali o anche test basati sul comportamento.

Il vantaggio è che sai - immediatamente - quando qualcuno ha rotto la build. Questo significa che A) Hanno commesso un codice che impedisce la compilazione, il che rovinerebbe chiunque abbia fatto un 'aggiornamento', oppure B) Hanno commesso un codice che ha interrotto alcuni test, il che significa che hanno introdotto un bug che deve essere corretto, oppure i test devono essere aggiornati per riflettere la modifica del codice.

Se sei uno sviluppatore solista, CI non è abbastanza utile se hai l'abitudine di eseguire i test prima di un commit, che è ciò che dovresti fare. Detto questo, potresti sviluppare una cattiva abitudine di lasciare che l'IC faccia i test per te.

Come programmatore solista, si tratta principalmente di disciplina. L'uso di CI è un'abilità utile da avere, ma vuoi evitare di sviluppare cattive abitudini che non si traducano in un ambiente di squadra.

Answer 2

Come altri hanno notato, CI ha vantaggi per uno sviluppatore solista. Ma la domanda che ti devi porre è; vale il sovraccarico? Se sei come me, probabilmente ci vorranno un'ora o due per configurare un sistema CI per un progetto, solo perché dovrò allocare un server, impostare tutto il networking e installare il software. Ricorda che il sistema CI ti farà risparmiare solo pochi secondi alla volta. Per uno sviluppatore solista, è improbabile che questi tempi si sommino a più del tempo impiegato per eseguire la configurazione dell'IC.

Tuttavia, se non hai mai configurato un sistema CI prima, ti consiglio di farlo solo per motivi di apprendimento. Non ci vuole così tanto tempo che non vale l'esperienza di apprendimento.

Answer 3

Il vantaggio di CI sta nella capacità di scoprire in anticipo quando un check in ha interrotto la build. Puoi anche eseguire la tua suite di test automatici contro la build, nonché eseguire qualsiasi tipo di strumento per fornirti metriche e simili.

Ovviamente, questo è molto prezioso quando si dispone di un team di committenti, non tutti diligenti per verificare eventuali modifiche. Come sviluppatore solista, non è altrettanto prezioso. Presumibilmente, si eseguono i test unitari e forse anche i test di integrazione. Tuttavia, ho visto diverse occasioni in cui lo sviluppatore si dimentica di archiviare un file da un set.

La build CI può anche essere considerata come la tua "release" costruire. L'ambiente dovrebbe essere stabile e non influenzato da qualsiasi gizmo di sviluppo che aggiungi alla tua macchina. Dovrebbe consentire di riprodurre sempre una build. Questo può essere utile se aggiungi una nuova dipendenza al tuo progetto e dimentichi di impostare l'ambiente di compilazione della versione per tenerne conto.

Answer 4

Se è necessario supportare più compilatori, è utile disporre di un sistema di compilazione CI per eseguire tutto ciò mentre si sviluppa in un unico IDE. Il mio codice si basa su Vc6 tramite VS2008 in x86 e x64 si basa su VS2005 & amp; 8, quindi sono 7 build per progetto per configurazione del progetto ... Avere un sistema CI significa che posso sviluppare in un IDE e lasciare che il sistema CI dimostri che tutti i compilatori che supporto supportano ancora di costruire.

Allo stesso modo, se stai creando librerie che vengono utilizzate da più progetti, CI assicurerà che funzionino con TUTTI i progetti piuttosto che con quello con cui stai lavorando in questo momento ...

Answer 5

La verità è che l'integrazione continua ha più senso nei team. I singoli sviluppatori possono anche ottenere alcuni vantaggi, devi decidere tu stesso se sono abbastanza per contrastare il tempo che investi nella creazione di un sistema CI.

• Se hai dimenticato di archiviare alcuni file necessari, il repository contiene una versione non funzionante, anche se funziona sul tuo computer. CI rileverebbe quel caso.
• Se il tuo server CI funziona su un altro computer, può indicare dipendenze dal tuo ambiente di compilazione. Mezzi, build e tutti i test possono funzionare sul tuo dev-box, ma su un'altra macchina alcune dipendenze non sono soddisfatte e la build si interrompe.
• Le build giornaliere possono indicare che il tuo software precedente non funziona con l'ultimo aggiornamento del sistema operativo / compilatore / libreria ...
• Se il tuo sistema CI ha un archivio di artefatti da build, puoi facilmente ottenere una distribuzione di una versione precedente del tuo software.
• Alcuni CI hanno una bella interfaccia per mostrarti le metriche sulla tua build, hanno collegamenti a documentazione generata automaticamente e cose del genere.

Answer 6

Usiamo il nostro sistema CI per eseguire build di rilascio (così come le solite build automatiche "on-commit").

Essere in grado di fare clic su un pulsante che dà il via a una build di rilascio che attraversa tutti i processi per rilasciare un'installazione è:

• veloce (posso andare dritto con altre cose, e gira su una macchina separata quindi non mi rallenta);
• ripetitivo (non dimentica nulla, inclusa la copia dell'installazione nella cartella di rilascio e la notifica a tutti coloro che devono sapere)
• affidabile (nessun errore, a differenza di un essere umano!).

In un ambiente Agile, dove prevedi di distribuire software funzionante ogni 2-4 settimane, vale sicuramente la pena farlo, anche in un team di 1.

Answer 7

CI beneficia uno sviluppatore solista, nel senso che sei consapevole se hai dimenticato di fare il check-in (perché la build verrà interrotta). Il suo valore di integrazione viene ridotto quando non ci sono altri sviluppatori.