Qual è il punto dei servizi di Continuous Integration come Travis CI?

Non ho familiarità con questi servizi, ma CI in generale va bene per

Elimina la scusa "Costruisci sulla mia macchina" per commettere un cattivo lavoro.

Se non funziona in CI, non funziona.

Puoi quindi prendere il codice di lavoro conosciuto da lì e usarlo per cose come la Distribuzione continua.

Alcuni forniscono una cronologia in modo che tu possa taggare la Versione 1.0, 1.1 ecc. quindi è facile tornare a loro se c'è qualche problema di unforseen nella nuova versione o hai solo bisogno di rilasciare la vecchia versione.

1. Sei sicuro che tutti eseguiranno i test? Per esempio. quelli commettono quando sei in ritardo per l'aereo - e quel cambiamento è piccolo e davvero-davvero non può rompere nulla.
2. Sei sicuro di voler eseguire l'intera suite di test sul tuo sistema prima di ogni push? Alcuni test sono eseguiti per ore (automazione dell'interfaccia utente) o eseguono strumenti lenti come valgrind .
3. Sei sicuro di eseguire la suite di test su tutte le piattaforme supportate? Per esempio. se si esegue un'applicazione C ++ su Linux / Mac OS X / Windows è banale interrompere la compilazione su altre piattaforme se non si esegue il test lì. Immagina che a volte potresti persino dover testare separatamente Windows7 e Windows8.
4. Build / package l'intera applicazione potrebbe richiedere un po 'di tempo. CI ti consente semplicemente di scaricare il pacchetto creato sul server.

Uno dei modi più comuni in cui ho visto la gente infrangere la build è quando stanno lavorando su più cose contemporaneamente, e controllano ciò che pensano siano tutte le modifiche necessarie per un particolare compito che hanno appena finito.

Risulta che hanno perso un file o hanno verificato una modifica che faceva parte di un'attività separata che non è ancora stata completata.

In casi come questo, i test probabilmente girano tutti correttamente sulla loro macchina. Ma il codice impegnato non crea più, esegue e passa tutti i test.

In sostanza, se lo strumento CI può ottenere l'ultima versione dal controllo del codice sorgente, crearlo ed eseguire i test, puoi essere sicuro che chiunque può ottenere l'ultima e ottenere una base di codice funzionante.

L'idea chiave con integrazione continua è quella di avere sempre una build funzionante , ovvero una build che si completa con successo e supera i test unitari in ambiente di costruzione canonico. Questo perché è molto più facile assicurarsi che la build funzioni sempre che riparare una build che si è rotta per errore qualche tempo fa, esp. quando nessuno è abbastanza sicuro di chi lo ha rotto e quando.

Con l'integrazione continua, saprai immediatamente se:

• Qualcuno ha accidentalmente eseguito il codice senza includere un nuovo file sorgente
• Qualcuno ha usato per errore un percorso di riferimento assoluto
• Qualcuno si è appena fatto un casino

Il che significa che verrà risolto immediatamente mentre la memoria delle modifiche è ancora fresca.