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

Se stai facendo un progetto solista, useresti gli strumenti CI per creare da un repository? Ho usato Hudson e Cruise Control in un ambiente di squadra, dove è essenziale costruire non appena qualcuno controlla qualcosa.

Penso che il valore del controllo della versione sia ancora ovvio, ma devo costruire dopo ogni commit, visto che avrei appena costruito sul mio computer locale e nessun altro lo sta impegnando?

Bene, sto pianificando di utilizzare uno strumento di integrazione continua su un progetto e sono lo sviluppatore unico. La necessità arriva perché

1. Un obiettivo è renderlo multipiattaforma e avere uno strumento di integrazione ti aiuta a controllare implicitamente (di base) la tua app su più piattaforme dopo aver apportato le modifiche al repository di integrazione (o quello centrale, o qualunque sia quello che sarà usato come autorevole).
2. Il progetto è stato creato per un lungo periodo, quindi dovrò lavorare con un team in seguito. Non ho intenzione di reclutare nessuno fino al 2012, quindi la cosa dell'integrazione continua può attendere il momento, fino a quando 1. diventerà la priorità.

Oltre alla preparazione multipiattaforma e al lavoro di gruppo, non vedo la necessità. La cosa principale è avere un qualche tipo di software di controllo del codice sorgente e avere diversi repository per conservare i backup. Ciò ti aiuterà a configurare strumenti di costruzione intorno ad esso quando necessario.

Per quanto riguarda i tempi di compilazione, sto usando Mercurial e sto configurando un repository di integrazione che non è il repository di lavoro di squadra. Quindi, spingi i cambiamenti nel repository del lavoro di squadra fino a quando sento che è il momento di provare a costruire il sistema di integrazione. Quindi spingo dal repository del lavoro di squadra al repository di integrazione e questo attiverà la build. Quindi aggiungo anche una sceneggiatura che richiamerà il repository del lavoro di squadra nel repository di integrazione una volta al giorno.

Qui presumo che lavoro quasi tutti i giorni sul mio progetto, ma non è sempre vero. Devi impostare un tempismo di compilazione relativo alla frequenza con cui hai bisogno di compilazioni. In una società di giochi in cui ho lavorato prima, abbiamo usato CruiseControle e ha costruito una build completa ogni ora. Potremmo anche forzare una build ogni volta che lo desideriamo, se necessario.

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

Dopo una breve riflessione, suggerirei che potrebbe anche essere più importante per uno sviluppatore solista che per una squadra.

Al livello più elementare un server CI dimostra che è possibile creare la propria applicazione da zero da fonti impegnate - in combinazione con una serie decente di test dovrebbe dimostrare che è possibile creare ed eseguire da zero.

Dal momento che una delle cose che cerco di fare è assicurarsi che la mia build includa un pacchetto distribuibile, sai anche che puoi andare a prendere qualcosa da distribuire (pulito e da uno stato / versione nota).

In effetti ora, quando esegui File | Nuovo progetto, probabilmente dovresti includere la creazione o l'aggiunta al tuo repository e l'impostazione del tuo script di build CI e della configurazione di distribuzione (anche se si tratta solo di comprimere un mucchio di cose per la distribuzione xcopy)

Addendum (2016) - al giorno d'oggi il mio sistema di elementi della configurazione sarà anche parte integrante del mio processo di distribuzione, quindi il suo valore è aumentato e non eseguirò assolutamente nessun progetto consegnabile senza di esso. La distribuzione automatizzata dei pulsanti elimina molto il processo e, in qualche modo, modellare o formare un server di build è parte integrante di questo.

Quando sono l'unico a impegnarmi, costruisco e collaudo prima di impegnarmi davvero. Di solito uso un target makefile come:

make sense

Che configura, costruisce, esegue tutti i test (consapevole di Valgrind), esegue i lint, ecc. Come so che sarò l'unico a spingere, non ho davvero bisogno del potere 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 il push, il server CI potrebbe essere un po 'over kill. Una regola ben scritta secondo cui l'autore di qualunque cosa abbia rotto l'ultima build compra la pizza venerdì di solito fa funzionare le cose molto bene :)

Se entra in una situazione in cui un progetto è chiaramente diviso in sottosistemi che hanno i loro leader, devi davvero contemplare l'uso 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 davvero prendere in considerazione l'uso di qualcosa come Hudson, anche se sei 'solo' in quel progetto. Ciò è particolarmente vero se si ramifica / riconduce 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 da solista là fuori. La maggior parte di noi lascerà un po 'slittare i propri standard di qualità se ha fretta se pensa che sia abbastanza facile da risolvere in seguito. Se si commette software in quello stato, si ha essenzialmente una base di codice inutile memorizzata nel controllo del codice sorgente.

Se aderisci correttamente (cioè, non salti i test e ti assicuri che si costruisca ogni volta che commetti) CI ti costringe ad aderire a uno standard di qualità superiore a quello che faresti se lo facessi comunque.

È importante se vuoi ridurre i tempi di attesa per vedere se tutto procede ancora bene. Anche se puoi far sì che il tuo IDE compili roba per te non appena salvi, non esegue automaticamente i test unitari, quindi il mio server CI esegue i test unitari, i rapporti sulla copertura dei casi di test e altre analisi di qualità del mio codice non appena Lo spingo.

L'unico trigger che devo fare è inviare le mie attuali modifiche al controllo della versione e posso tornare alla codifica. E mentre sto pensando alla codifica, il sistema CI è impegnato a sfornare facendo i rapporti sulla qualità a lungo ventoso che guarderò di tanto in tanto quando il mio cervello si cullerà.

Ho una macchina VMWare separata sullo stesso laptop che esegue le compilazioni per il codice che invio. Per fare ciò ottengo semplicemente un'immagine VMWare Linux chiavi in ​​mano e installo jenkins usando apt-get ed eseguo alcune piccole modifiche alla configurazione.