Quali vantaggi offrono gli strumenti di integrazione continua in un progetto solista?

Bene, sto pensando di utilizzare uno strumento di integrazione continua su un progetto e io sono lo sviluppatore unico. Il bisogno viene perché

1. Un obiettivo è quello di renderlo multipiattaforma e avere uno strumento di integrazione ti aiuta a controllare in modo implicito (base) la tua app su diverse piattaforme dopo aver trasferito le tue modifiche nel repository di integrazione (o centrale, o qualunque altra cosa sia quello che sarà usato come autorevole).
2. Il progetto è costruito a lungo termine, quindi avrò bisogno di lavorare con un team in seguito. Non ho intenzione di reclutare nessuno fino al 2012, quindi la cosa dell'integrazione continua può aspettare il momento, fino a quando 1. diventa la priorità.

Al di là della preparazione multipiattaforma e del lavoro di squadra, non ne vedo la necessità. La cosa principale è avere una sorta di software di controllo del codice sorgente e disporre di diversi repository per conservare i backup. Ciò ti aiuterà a configurare gli strumenti di creazione attorno a esso quando necessario.

Riguardo ai tempi di costruzione, sto utilizzando Mercurial e sto configurando un repository di integrazione che non è il repository di teamwork. Quindi, spingere i cambiamenti nel repository di lavoro di squadra fino a quando ritengo che sia il momento di fare in modo che il sistema di integrazione provi a costruire. Poi spingo dal repository di lavoro di squadra al repo di integrazione e questo attiverà la compilazione. Poi aggiungo anche uno script che estrae il repository di lavoro di squadra nel repository di integrazione una volta ogni giorno.

Qui presumo di lavorare quasi tutti i giorni sul mio progetto, ma non è sempre vero. Devi impostare un cronometraggio relativo alla frequenza con cui hai bisogno di build. In una società di giochi in cui ho lavorato in passato, abbiamo utilizzato CruiseControle e abbiamo costruito una compilazione completa ogni ora. Potremmo anche forzare una build ogni volta che volevamo, se necessario.

Per un progetto casa, una volta al giorno potrebbe già essere "spesso". Il requisito principale sarebbe quello di consentire facilmente all'utente di forzare l'avvio di una build.

Dopo una breve riflessione ti suggerirei che potrebbe essere più importante per uno sviluppatore solista piuttosto che per un team.

Al livello di base, un server CI dimostra che è possibile creare l'applicazione da zero dalla fonte specificata; combinata con una serie di test decente, è necessario dimostrare che è possibile creare ed eseguire da zero.

Dato che una delle cose che cerco di fare è assicurarmi che la mia build includa un pacchetto deployabile, sai anche che puoi andare a prendere qualcosa da distribuire (pulito e da uno stato / versione conosciuti).

In effetti ora, quando esegui File | Nuovo progetto, dovresti probabilmente includere la creazione o l'aggiunta al tuo repository e configurare il tuo script di compilazione e configurazione della configurazione (anche se è solo per comprimere una pila di cose per la distribuzione di xcopy)

Addendum (2016) - al giorno d'oggi il mio sistema CI sarà anche parte integrante del mio processo di implementazione, quindi il suo valore è aumentato e non eseguirò assolutamente nessun progetto deliverable senza di esso. La distribuzione automatica dei pulsanti richiede molto stress dal processo e in qualche modo, forma o forma, un server di build è parte integrante di questo.

Quando sono l'unico a impegnarmi, costruisco e collaudo prima che effettivamente sto commettendo. Di solito uso un target makefile come:

make sense

Che configura, costruisce, esegue tutti i test (valgrind aware), esegue i lint, ecc. Come so che sarò l'unico a spingere, non ho davvero bisogno della potenza di qualcosa come Hudson.

Inoltre, in un ambiente in cui ci sono diversi rami che alimentano un repository principale, se tutti seguono il pull sempre prima di eseguire il commit o push, il server CI potrebbe essere un po 'sopra l'uccisione. Una regola ben scritta secondo cui l'autore di ciò che ha rotto l'ultima build acquista la pizza di venerdì, di solito mantiene le cose senza intoppi:)

Se si entra in una situazione in cui un progetto è chiaramente diviso in sottosistemi che hanno i propri leader, è veramente necessario prendere in considerazione l'utilizzo di qualcosa come Hudson. Qualcuno potrebbe testare localmente, perdere una gara con un altro sottosistema e finire per spingere qualcosa di tossico.

Inoltre, se stai mantenendo un fork di un progetto in rapido movimento (ad esempio, il tuo set di patch per il kernel Linux), dovresti prendere in considerazione l'idea di usare qualcosa come Hudson, anche se sei "solo" su quel progetto . Questo è particolarmente vero se si dirama / ri-base direttamente dalla linea principale.

Non direi che questo è solo un bel bonus, direi che è vitale per l'ingegneria del software di alta qualità per noi artisti solisti là fuori. Molti di noi lasceranno che i loro standard di qualità scivolino un po 'se corrono se pensano che sia abbastanza facile da risolvere in seguito. Se esegui il commit del software in quello stato, in pratica hai una base di codice priva di valore memorizzata nel tuo controllo sorgente.

Se rispettato correttamente (ovvero, non salti i test e ti assicuri che si costruisca ogni volta che esegui il commit) CI ti obbliga ad aderire a uno standard di qualità più elevato di quello che avresti se lo avessi appena commesso comunque .

È importante se vuoi ridurre il tempo di attesa per vedere se tutto procede ancora bene. Sebbene tu possa ottenere il tuo IDE per compilare materiale per te non appena esegui il salvataggio, non esegue automaticamente i test unitari, quindi ho il mio server CI che esegue i test unitari e i rapporti di copertura del caso di test e altre analisi di qualità del mio codice non appena Lo spingo.

L'unico trigger che devo fare è spingere le mie attuali modifiche al controllo della versione e posso tornare alla codifica. E mentre sto pensando alla codifica, il sistema IC è impegnato a fare i lunghi rapporti di qualità che guarderò di tanto in tanto quando il mio cervello va in una fase di calma.

Ho una macchina VMWare separata sullo stesso laptop che crea le build per il codice che spingo. Per farlo, ho appena ottenuto un'immagine VMWare di Linux chiavi in mano e installo il jenkins usando apt-get e faccio alcune modifiche minori alla configurazione .