Share
Travis CI erleichtert die Arbeit im Team für ein Softwareprojekt mit automatisierten Builds. Diese Builds werden automatisch ausgelöst, wenn jeder Entwickler seinen Code in das Repository eincheckt. In diesem Artikel erfahren Sie, wie wir Travis CI problemlos in unser auf Github gehostetes Projekt integrieren können. Mit Automatisierung, Benachrichtigung und Testen können wir uns auf das Codieren und Erstellen konzentrieren, während Travis CI die harte Arbeit der kontinuierlichen Integration durchführt!
Travis CI ist eine gehostete Continuous Integration-Plattform, die für alle auf Github gehosteten Open Source-Projekte kostenlos ist. Mit nur einer Datei namens .travis.yml Wir enthalten einige Informationen zu unserem Projekt und können mit jeder Änderung unserer Codebasis in der Master-Zweigstelle, anderen Zweigstellen oder sogar einer Pull-Anfrage automatisierte Builds auslösen.
Bevor wir mit der Integration von Travis in unser Projekt beginnen, sind die folgenden Voraussetzungen hilfreich:
Im Mittelpunkt der Verwendung von Travis steht das Konzept von kontinuierliche Integration (CI). Nehmen wir an, wir arbeiten an einem Feature, und nachdem wir mit dem Codieren fertig sind, werden wir es normalerweise tun bauen das Projekt, um die ausführbare Datei sowie andere Dateien zu erstellen, die zum Ausführen der Anwendung erforderlich sind. Nach Abschluss des Builds müssen Sie alle Tests durchführen, um sicherzustellen, dass alle Tests erfolgreich sind und alles wie erwartet funktioniert.
Der letzte Schritt ist sicherzustellen, dass das, was wir codiert haben, tatsächlich funktioniert, auch nachdem wir es in den Hauptcode integriert haben. An diesem Punkt bauen und testen wir erneut. Wenn der integrierte Build erfolgreich ist, können wir davon ausgehen, dass das Feature vollständig implementiert wurde. Travis CI automatisiert diesen exakten Schritt des Auslösens eines Builds und eines Tests bei jeder Integration in den Master-Zweig, anderen Zweigstellen oder sogar einer Pull-Anforderung, wodurch die Zeit bis zur Erkennung eines potenziellen Integrationsfehlers verkürzt wird.
In den folgenden Abschnitten nehmen wir ein einfaches Projekt und lösen einen fehlerhaften Build aus, korrigieren ihn und übergeben ihn. Wir werden auch sehen, wie Travis CI problemlos mit Github-Pull-Requests funktioniert.
Wenn wir auf der Haupt-Homepage landen, können wir auch die "Geschäftigkeit" vieler Open Source-Projekte erkennen, die automatisiert ablaufen. Lassen Sie uns die Schnittstelle dekonstruieren und die verschiedenen Teile verstehen:
Bevor wir Travis CI integrieren, erstellen wir ein einfaches "Hallo Welt" -Projekt und einige Build-Aufgaben. Travis unterstützt verschiedene Programmiersprachen wie Python, Ruby, PHP und JavaScript mit NodeJS. Für unsere Demo verwenden wir NodeJS. Lassen Sie uns eine sehr einfache Datei erstellen hallo.js wie auf der Hauptseite von NodeJS definiert:
Accentsconagua
var http = erfordern ('http'); http.createServer (function (req, res) res.writeHead (200, 'Content-Type': 'text / plain'); res.end ('Hello World \ n') // fehlt das Semikolon Fehler beim Build). listen (1337, '127.0.0.1'); console.log ('Server läuft unter http://127.0.0.1:1337/'); Beachten Sie, dass ein Semikolon fehlt, sodass später in JSHint ein JavaScript-Interpreter dies erkennen und einen Fehler auslösen kann. Wir werden das Projekt mit einem Task Runner namens GruntJS erstellen, der JSHint enthält. Dies ist natürlich eine Illustration, aber in echten Projekten können wir verschiedene Test-, Veröffentlichungs-, Flint- und Hinweisaufgaben einschließen.
Um die verschiedenen Pakete anzuzeigen, die für GruntJS, JSHint und andere erforderlich sind, erstellen wir eine zweite Datei mit dem Namen package.json. Diese Datei enthält zunächst den Namen und die Versionsnummer unserer einfachen Anwendung. Als Nächstes definieren wir die benötigten Abhängigkeiten mit devDependencies Dazu gehören Pakete für GruntJS, einschließlich JSHint. Mit Skripte, Wir werden Travis CI anweisen, die Testsuite und den Befehl auszuführen Grunzen - Verbose. Lassen Sie uns den gesamten Inhalt der Datei anzeigen: package.json:
"name": "node-travis", "version": "0.1.0", "devDependencies": "grunt": "0.4.1", "grunt-cli": "0.1.9", "grunt" -contrib-jshint ":" 0.6.0 "," scripts ": " test ":" grunt --verbose "
Als nächstes bereiten wir das vor Gruntfile.js Dazu gehören alle Aufgaben, die zur Ausführung unseres Builds erforderlich sind. Der Einfachheit halber können wir nur eine Aufgabe hinzufügen - das JavaScript-Flinting mit JSHint.
module.exports = function (grunt) grunt.initConfig (jshint: all: ['Gruntfile.js', 'hello.js']); grunt.loadNpmTasks ('grunt-contrib-jshint'); grunt.registerTask ('default', 'jshint'); ; Schließlich führen wir den Build aus, der nur eine Aufgabe enthält, nachdem wir alle zugehörigen Pakete mit heruntergeladen haben npm installieren:
$ npm installiere $ grunt
Wie erwartet, wird der Build nicht bestanden, da JSHint ein fehlendes Semikolon erkennt. Aber wenn wir das Semikolon wieder in die hallo.js Datei und führen Sie die grunzen Befehl noch einmal, werden wir sehen, dass der Build passieren wird.
Nachdem wir nun ein einfaches Projekt vor Ort erstellt haben, werden wir dieses Projekt auf unser Github-Konto übertragen und Travis CI integrieren, um den Build automatisch auszulösen.
Der allererste Schritt bei der Integration von Travis CI ist das Erstellen einer Datei mit dem Namen .travis.yml enthält die wesentlichen Informationen über die Umgebung und die Konfigurationen, die der Build ausführen soll. Der Einfachheit halber nehmen wir nur die Programmierumgebung und die Version auf. In unserem einfachen Projekt ist dies die NodeJS-Version 0,10. Der endgültige Inhalt der Datei .travis.yml wird wie folgt sein:
Sprache: node_js node_js: - "0.10"
Nun wird unser Projekt zusammen mit den folgenden Dateien bestehen README.md und .Gitignore nach Bedarf:
$ Baum. | - .travis.yml | - Gruntfile.js | - hello.js | - .gitignore | - README.md '- package.json
Lassen Sie uns nun ein Git-Repository erstellen und zu einem neuen Remote-Repository wechseln, das auf Github gehostet wird:
git init git commit -m "first commit" git Remote-Ursprungsort hinzufügen [email protected]: [Benutzername] / [Repository] .git git Push -u Ursprungsmaster
Melden Sie sich als Nächstes bei Travis CI an und autorisieren Sie Travis CI, auf Ihr Github-Konto zuzugreifen. Besuchen Sie anschließend Ihre Profilseite, um den Haken für das Github-Repository zu aktivieren, um automatisierte Builds mit Travis CI auszulösen.
Als letzten Schritt, um unseren ersten Build auszulösen, müssen wir zu Github pushen. Entfernen wir das Semikolon in der Datei hallo.js um einen fehlerhaften Build zu erstellen und dann zu Github zu gelangen. Dadurch wird der automatisierte Build in Travis CI ausgelöst. Lass uns die URL besuchen: https://travis-ci.org/[Benutzername(/[repo] um den ersten Build zu sehen!
git add hello.js git commit -m "Semikolon entfernt" git push
Dieses fehlerhafte Build im obigen Beispiel ist wirklich eine einfache Illustration. Diese Situation reflektiert jedoch etwas, das in unseren realen Projekten passieren könnte - wir versuchen, unseren Code zu integrieren, und der automatisierte Build schlägt fehl. Nach Abschluss jedes Builds sendet Travis CI standardmäßig E-Mails an den Commit-Autor und den Besitzer des Repositorys. Auf diese Weise wird der Entwickler, der den Code gepusht hat, sofort benachrichtigt und kann dann die Integrationsfehler beheben. In unserem Fall fügen wir einfach das fehlende Semikolon ein und drücken noch einmal zu Github.
git add hello.js git commit -m "hat Semikolon hinzugefügt, um den Build zu übergeben" git push
Hurra! Der automatisierte Build ist dieses Mal vergangen. Unser Code ist integriert, um alle erforderlichen Tests zu bestehen. Jedes Mal, wenn wir versuchen, unsere Änderungen zu integrieren, sei es im Master-Zweig oder sogar in anderen Zweigstellen, löst Travis CI einen automatisierten Build aus.
Sobald wir Travis CI in unser Projekt integriert haben, wird eine Pull-Anfrage auch einen automatisierten Build auslösen. Dies ist äußerst nützlich für den Repository-Besitzer oder den Entwickler, der für die Zusammenführung der Codebasis verantwortlich ist. Mal sehen, wie Travis CI darauf hinweist, ob die Pull-Anfrage gut ist oder nicht.
Lassen Sie uns zunächst ein anderes Github-Konto verwenden, um das ursprüngliche Repository zu verzweigen und die Anforderung mit den folgenden Schritten zu ziehen:
Um einen fehlerhaften Build in der Pull-Anforderung zu simulieren, entfernen wir erneut das Semikolon in der Datei hallo.js, Commit und Push der Änderungen und schließlich Pull-Anforderung.
Bei jeder Pull-Anforderung wird Travis CI den Build automatisch auslösen. Dieses Mal können wir auch die besuchen "Pull-Anfragen" Klicken Sie auf die Registerkarte, um den Verlauf aktueller oder früherer Builds anzuzeigen, die aufgrund einer Pull-Anforderung ausgelöst wurden.
Wenn Travis CI den Build abgeschlossen hat und wir die Pull-Request-Seite aus dem ursprünglichen Repository aufrufen, werden wir feststellen, dass Travis CI einige Änderungen an der Benutzeroberfläche angefügt hat, um uns zu warnen, dass der Build fehlgeschlagen ist.
Dieser fehlerhafte Build-Status wird dem Repository-Besitzer sowie dem Entwickler, der die Pull-Anforderung gestellt hat, sofort benachrichtigt. Abhängig vom Grund des fehlerhaften Builds kann dieser nun mit einem anderen Commit in demselben Zweig behoben werden. Fügen wir also das Semikolon hinzu und ziehen Sie ein letztes Mal eine Anforderung ab. Github aktualisiert automatisch auch die Pull-Request-Seite.
Und schließlich, wenn wir zur Pull-Request-Seite des ursprünglichen Repositorys zurückkehren, wird diesmal ein "grünes" Signal zu sehen sein, um fortzufahren und eine Zusammenführung durchzuführen, während unser Build vorüber ist!
Die Datei .travis.yml definiert die Build-Konfigurationen. In unserem Beispiel wurden nur der Sprachtyp und die Version angegeben. Wir können jedoch weitere nützliche hinzufügen:
Sprache: Rubinrvm: - 1.9.3
before_script: - git config --global user.name [meinname]
Benachrichtigungen: E-Mail: false irc: "chat.freenode.net # travis"
.travis.yml Wie Sie sehen können, ist die Datei .travis.yml wird beim Auslösen automatisierter Builds sehr wichtig. Wenn diese Datei nicht gültig ist, löst Travis CI den Build nicht bei jedem Push an Github aus. Daher ist es wichtig sicherzustellen, dass wir über eine gültige Datei verfügen, die von Travis CI korrekt interpretiert wird. Dazu installieren wir einen Edelstein namens travis-lint und führen die Datei aus .travis.yml
$ gem install travis-lint $ travis-lint .travis.yml
Es ist wirklich hilfreich, ein kleines Bild mit einzuschließen, um den aktuellen Status des Builds anzuzeigen. Auf das Bild selbst kann über das URL-Muster zugegriffen werden http://travis-ci.org/[Benutzername?/[repository-Name.png. Eine andere Möglichkeit, schnell auf die in verschiedenen Formaten eingebetteten Bilder zuzugreifen, bietet die Travis CI-Projektseite. Beispielsweise können wir das Markdown-Format kopieren und in das Projekt einbetten README.md Datei.
Eine weitere gute Möglichkeit, den Build-Status verschiedener Open Source-Projekte beim Surfen in Github zu verfolgen, ist die Installation einer Browsererweiterung. Dadurch werden die Build-Status-Bilder direkt neben den Projektnamen angezeigt.
Hier finden Sie einige Ressourcen zum Konzept der kontinuierlichen Integration sowie zum Lernen und Integrieren von Travis CI in unsere Github-Projekte:
Eine fantastische Methode, um zu erfahren, was und wie die verschiedenen Build-Konfigurationen in das System aufgenommen werden sollen .travis.yml Diese Datei dient zum Durchsuchen vieler beliebter Open Source-Repositorys, in die bereits Travis CI integriert ist. Hier sind ein paar:
Ich hoffe, dies gab Ihnen eine kurze Einführung, wie Sie Travis CI problemlos in unsere Github-Projekte integrieren können. Es ist wirklich einfach zu bedienen. Probieren Sie es aus und machen Sie die kontinuierliche Integration zu einem Kinderspiel für Ihr Team!
