Share
Travis CI facilita il lavoro in team per un progetto software con build automatizzati. Queste build vengono attivate automaticamente quando ogni sviluppatore controlla il codice nel repository. In questo articolo, esamineremo come integrare facilmente Travis CI con il nostro progetto, che è ospitato su Github. Con l'automazione, la notifica e i test in atto, possiamo concentrarci sulla nostra codifica e creazione, mentre Travis CI fa il duro lavoro di integrazione continua!
Travis CI è una piattaforma di integrazione continua ospitata, gratuita per tutti i progetti open source ospitati su Github. Con solo un file chiamato .travis.yml contenenti alcune informazioni sul nostro progetto, possiamo attivare build automatici con ogni modifica alla nostra base di codice nel ramo principale, in altri rami o anche in una richiesta di pull.
Prima di iniziare con il modo in cui possiamo integrare Travis con il nostro progetto, saranno utili i seguenti prerequisiti:
Al centro dell'utilizzo di Travis, è il concetto di integrazione continua (CI). Diciamo che stiamo lavorando su una funzione e, una volta terminata la codifica, lo faremo in genere costruire il progetto in modo da creare l'eseguibile e altri file necessari per eseguire l'applicazione. Una volta completata la compilazione, le buone pratiche includono l'esecuzione di tutti i test per assicurarsi che siano tutti in transito e tutto funzioni come previsto.
L'ultimo passo è garantire che tutto ciò che abbiamo codificato funzioni effettivamente anche dopo averlo integrato nel codice principale. A questo punto costruiamo e testiamo di nuovo. Se la compilazione integrata ha esito positivo, possiamo considerare che la funzione è stata completamente implementata. Travis CI automatizza questo esatto passaggio di attivazione di una build e verifica su ogni integrazione al ramo principale, ad altri rami o anche a una richiesta pull, accelerando il tempo di rilevamento di un potenziale bug di integrazione.
Nelle sezioni seguenti, prenderemo un semplice progetto e innesceremo una build in errore, la correggeremo e poi la passeremo. Vedremo anche come Travis CI funziona facilmente con le richieste pull di Github.
Quando atterriamo sulla homepage principale, possiamo anche vedere il "busyness" di molti progetti open source che passano attraverso la build automatizzata. Decostruiamo l'interfaccia e comprendiamo le varie parti:
Prima di integrare Travis CI, creeremo un semplice progetto "ciao mondo" e creeremo alcune attività di compilazione. Travis supporta vari linguaggi di programmazione tra cui Python, Ruby, PHP e JavaScript con NodeJS. Ai fini della nostra demo, useremo NodeJS. Creiamo un file molto semplice hello.js come definito sul sito Web principale di NodeJS:
Accentsconagua
var http = require ('http'); http.createServer (function (req, res) res.writeHead (200, 'Content-Type': 'text / plain'); res.end ('Hello World \ n') // il punto e virgola mancante fallire la build). listen (1337, '127.0.0.1'); console.log ('Server in esecuzione all'indirizzo http://127.0.1.11337/'); Si noti che c'è un punto e virgola mancante in modo che in seguito su JSHint, un linter di JavaScript sarà in grado di rilevare questo e segnalare un errore. Costruiremo il progetto usando un task runner chiamato GruntJS che includerà JSHint. Questa è ovviamente un'illustrazione, ma nei progetti reali, possiamo continuare a includere varie attività di test, pubblicazione, linting e suggerimenti.
Per indicare i vari pacchetti richiesti per GruntJS, JSHint e altri, creeremo un secondo file chiamato package.json. Questo file contiene innanzitutto il nome e il numero di versione della nostra semplice applicazione. Successivamente, definiremo le dipendenze necessarie con devDependencies che includerà i pacchetti relativi a GruntJS incluso JSHint. Con script, diremo a Travis CI di iniziare a eseguire la suite di test e il comando grunt --verbose. Vediamo il contenuto completo del file: package.json:
"nome": "node-travis", "versione": "0.1.0", "devDependencies": "grunt": "0.4.1", "grunt-cli": "0.1.9", "grunt" -contrib-jshint ":" 0.6.0 "," scripts ": " test ":" grunt --verbose "
Quindi, prepariamo il Gruntfile.js che includerà tutte le attività richieste per eseguire la nostra build. Per semplicità, possiamo includere solo un'attività: il linting di JavaScript con JSHint.
module.exports = function (grunt) grunt.initConfig (jshint: all: ['Gruntfile.js', 'hello.js']); grunt.loadNpmTasks ( 'grunt-contrib-jshint'); grunt.registerTask ('default', 'jshint'); ; Infine, eseguiremo la build che contiene una sola attività dopo aver scaricato tutti i pacchetti correlati installazione di npm:
$ npm installa $ grunt
Come previsto, la compilazione non passerà perché JSHint rileverà un punto e virgola mancante. Ma se mettiamo il punto e virgola indietro nel hello.js file ed esegui il grugnito comando ancora una volta, vedremo che la costruzione passerà.
Ora che abbiamo creato un progetto semplice localmente, lo inviamo al nostro account Github e integriamo Travis CI per attivare automaticamente la build.
Il primo passo per integrare Travis CI è creare un file chiamato .travis.yml che conterrà le informazioni essenziali sull'ambiente e le configurazioni per la build da eseguire. Per semplicità, includeremo solo l'ambiente di programmazione e la versione. Nel nostro semplice progetto, è la versione di NodeJS 0.10. Il contenuto finale del file .travis.yml sarà come segue:
lingua: node_js node_js: - "0.10"
Ora il nostro progetto sarà composto dai seguenti file insieme a README.md e .gitignore come richiesto:
$ albero. | - .travis.yml | - Gruntfile.js | - hello.js | - .gitignore | - README.md '- package.json
Ora creiamo un repository git e passiamo a un nuovo repository remoto ospitato su Github:
git init git commit -m "first commit" git remote add origin [email protected]: [nome utente] / [repository] .git git push -u origine master
Quindi, accedere a Travis CI e autorizzare Travis CI per accedere al proprio account Github. Successivamente, visita la pagina del tuo profilo per attivare il gancio del repository Github per attivare build automatici con Travis CI.
Come ultimo passo per attivare la nostra primissima build, dovremo spingere a Github. Rimuoviamo il punto e virgola nel file hello.js per creare una build fallita e poi spingere su Github. Questo attiverà la build automatizzata in Travis CI. Visitiamo l'URL: https://travis-ci.org/[username]/[repo] per vedere la prima build in corso!
git aggiungi hello.js git commit -m "rimosso punto e virgola" git push
Questa build fallita nell'esempio precedente è in realtà una semplice illustrazione. Ma questa situazione riflette ciò che potrebbe accadere nei nostri progetti reali: cerchiamo di integrare il nostro codice e la compilazione automatica fallisce. Per impostazione predefinita, al completamento di ogni generazione, Travis CI invierà e-mail all'autore del commit e al proprietario del repository. In questo modo, lo sviluppatore che ha inserito il codice viene immediatamente avvisato e può quindi correggere gli errori di integrazione. Nel nostro caso, inseriamo il punto e virgola mancante e passiamo a Github ancora una volta.
git aggiungi hello.js git commit -m "ha aggiunto il punto e virgola per passare la build" git push
Evviva! La build automatizzata è passata questa volta. Il nostro codice è integrato passando tutti i test richiesti. Ora ogni volta che proviamo ad integrare le nostre modifiche, sia che si tratti del ramo master o anche di altre filiali, Travis CI attiverà una build automatizzata.
Una volta che abbiamo integrato Travis CI nel nostro progetto, una richiesta pull attiverà anche una build automatizzata. Ciò è estremamente utile per il proprietario del repository o lo sviluppatore responsabile della fusione del codice base. Vediamo come Travis CI ti consiglierà se la richiesta pull è buona da unire o meno.
Innanzitutto, usando un altro account Github, forchiamo il repository originale e richiamiamo la richiesta con i seguenti passi:
Per simulare una build fallita nella richiesta pull, rimuoveremo nuovamente il punto e virgola nel file hello.js, impegnarsi e spingere le modifiche e infine tirare la richiesta.
Su ogni richiesta di pull, Travis CI attiverà automaticamente la build. Questa volta, possiamo anche visitare il "Pull Requests" scheda per vedere la cronologia delle build attuali o passate attivate a causa di una richiesta di pull.
Dopo che Travis CI completa la build, se visitiamo la pagina di richiesta di pull dal repository originale, vedremo che Travis CI ha aggiunto alcune modifiche all'interfaccia utente per avvisarci che la build non è riuscita.
Questo stato di build in errore verrà immediatamente notificato al proprietario del repository e allo sviluppatore che ha effettuato la richiesta di pull. E ora, a seconda del motivo della build fallita, può essere corretto con un altro commit nello stesso ramo. Quindi, aggiungiamo il punto e virgola e richiamiamo l'ultima richiesta. Github aggiornerà automaticamente anche la pagina di richiesta pull.
Infine, quando torniamo alla pagina di richiesta di pull del repository originale, questa volta vedremo un segnale "verde" per andare avanti e fare una fusione mentre la nostra build sta passando!
Il file .travis.yml definisce le configurazioni di build. Il nostro esempio include solo il tipo di lingua e la versione, ma possiamo aggiungere altri più utili come segue:
lingua: ruby rvm: - 1.9.3
before_script: - git config --global user.name [myname]
notifiche: email: false irc: "chat.freenode.net # travis"
.travis.yml Come puoi vedere, il file .travis.yml diventa molto importante nell'attivazione di build automatizzate. Se questo file non è valido, Travis CI non attiverà la build dopo ogni push su Github. Quindi, assicurandoci di avere un file valido che Travis CI interpreterà correttamente è importante. Per questo, installeremo un gioiello chiamato travis-lint ed eseguiremo il file .travis.yml
$ gem installa travis-lint $ travis-lint .travis.yml
È molto utile includere una piccola immagine per indicare lo stato corrente della build. L'immagine stessa è accessibile dal pattern URL http://travis-ci.org/[username]/[repository-name].png. Un altro modo per accedere rapidamente alle immagini incorporate in vari formati è nella stessa pagina del progetto di Travis CI. Ad esempio, possiamo copiare il formato Markdown e incorporare nel progetto README.md file.
Un altro modo interessante per tenere traccia degli stati di costruzione di vari progetti open source durante la navigazione su Github è installare una delle estensioni del browser. Questo metterà le immagini di stato della build in primo piano accanto a ciascun nome del progetto.
Ecco alcune risorse sul concetto di integrazione continua, nonché sull'apprendimento e l'integrazione di Travis CI nei nostri progetti Github:
Un modo fantastico per imparare cosa e come includere le varie configurazioni di costruzione nel .travis.yml il file è in realtà navigare attraverso molti dei popolari repository open source che già integrano Travis CI. Eccone alcuni:
Spero che questo ti abbia dato una breve introduzione su come possiamo integrare facilmente Travis CI nei nostri progetti Github. È davvero facile da usare, quindi provalo e rendi l'integrazione continua un gioco da ragazzi per il tuo team!
