Quando integrazione continua (come CruiseControl ) aggiunge valore a un progetto?
Fai fattori come
fai la differenza nel valore aggiunto dalla continua integrazione, o è qualcosa che vale sempre la pena?
Penso che aggiunga valore anche a una singola persona che inizia il progetto. Prima lo installi, più è facile e meno tempo dovrai spendere durante i periodi di crisi, preoccupandoti o desiderando di averlo.
Fin dall'inizio, si assicurerà che tutti i test unitari (anche se ce ne siano uno) verranno eseguiti tutte le volte che viene eseguito il check in. In caso contrario, ti baserai su di te per eseguirli ogni volta, e tu dimenticherò.
Nella mia esperienza è così facile in questi giorni con CC.Net o Jenkins, ecc. che non vale la pena aspettare. L'ho messo vicino allo stesso livello di necessità del controllo del codice sorgente.
Modifica: all'inizio ti sarà sempre meno "integrato" e più continuamente "costruttivo", ma man mano che verranno coinvolte più versioni e persone, allora sarà vera integrazione continua.
IMHO, vale sempre la pena. Anche se non si dispone di un singolo test di unità e l'integrazione non è altro che il controllo del progetto e la sua costruzione, si sta ancora uscendo. Se il tuo build CI ha successo, significa che qualsiasi idiota può controllare il tuo codice e crearlo. Questo probabilmente ti anticipa l'85% dei progetti software sul pianeta terra.
Direi anche che il valore scala con le dimensioni del progetto.
Il guadagno dipende da cosa lo usi. Se usi i test, vedi se interrompi la funzionalità, ecc., Ma a prescindere da ciò ottieni sempre un guadagno.
Sai se il codice sorgente nello stato attuale verrà creato o meno, perché il robot lo ha creato da zero.
Se qualcuno lo ha rotto, lo imparerai molto velocemente in modo che possa essere risolto.
Questo solo vale molto. Tutto il resto è solo extra.
L'integrazione continua ha solo lo stesso valore dei tuoi processi automatizzati.
Il tuo progetto dovrebbe avere una base in solidi processi automatici AND ripetibili. Assicurati che quanto segue sia automatico e deterministico:
- Number of Unit Tests
- How often changes are made
- Branch development
- Team Size
Questi sono tutti ortogonali al valore potenziale di un sistema di CI. Possono avere un impatto sul modo in cui implementate il sistema, su quante risorse richiede, ma non sul valore. Questo perché il valore dell'elemento della configurazione sta eseguendo il processo automatizzato spesso e automaticamente, il che porta a errori più rapidamente.
Penso che il dolore numero uno che è scomparso quando ho iniziato a usare un server di build sia stato il panico appena prima del rilascio in cui si apprendono tutti i tipi di dettagli nitidi su quali mancanze non sono mai state controllate nel controllo del codice sorgente, quali progetti smetti di compilare, quali progetti hanno test che smettono di funzionare, quali cambiamenti recenti hanno infranto i test di integrazione (quelli lenti che effettivamente colpiscono il server o guidano un browser web)
Il tempo investito nell'utilizzo di un build server (nel mio caso, TeamCity), è stato ripagato nella prima versione, facilmente.
-Numero di test di unità
I test unitari ben scritti eseguono circa il tempo necessario per compilare & può essere aggiunto come una fase di post-compilazione. Quindi questo non è un argomento per l'utilizzo del builder server. Il fatto che gli sviluppatori di solito non impostino i test unitari come fase di compilazione, è comunque un buon argomento. Inoltre, se hai test di integrazione lenti, un server di build è felice di eseguirli tutte le sere, durante la notte, ma non riavrai il tuo investimento in test di integrazione lenti a meno che un build server li stia facendo girare per te: la gente non lo fa t calcio manuale di test di integrazione lenti che spesso.
-Come spesso vengono apportate modifiche
Se il codice cambia di rado, allora dimenticherò quali unità di test unità devono essere eseguite, ecc. ecc. Se il codice cambia frequentemente, voglio compilazioni e prove frequenti per assicurarmi di essere sicuro correre con le forbici (cambiamenti rapidi = più errori umani e più velocemente il mio server di build può rilevarli per me, più velocemente posso correre con le forbici)
Sviluppo di branch
Prima di avere un controllo del codice sorgente, un server di build, ecc., generalmente ritenevo che la ramificazione fosse eccessiva per tenere mentalmente traccia di qualsiasi cosa. Quindi non so davvero se sia più facile o difficile fare lo sviluppo di un ramo senza un server di build. Penso che un team sarebbe più propenso a tentare lo sviluppo del ramo con un server di build.
-Team Size
Avere il controllo del codice sorgente mi permette di essere tranquillo riguardo agli sviluppatori che verificano un disastro-- Posso invertire la cosa, ma è il server di build che mi consente di scoprirlo, a volte minuti o ore dopo invece di settimane dopo.
Il valore si ridimensiona con le dimensioni della squadra e del progetto. Anche in scala con la complessità. Se si hanno diversi processi da eseguire, come test unitari, test di integrazione / sistema, analisi statica, generazione di metriche, packaging, implementazione, ecc., La complessità dei processi aumenta. L'automazione di questi è un grande vantaggio, anche se sei un team di uno (come me) o lavori su un progetto più piccolo.
Leggi altre domande sui tag builds continuous-integration configuration-management