Eine Einführung in die kontinuierliche Integration - Continuous
Integration - gibt es in der zweiundneunzigsten Episode des
Anwendungsentwickler-Podcasts. TL;DR Continuous Integration (CI)
führt Codeänderungen regelmäßig zusammen und prüft sie durch
automatisierte Builds und Tests. Dafür brauchst du ein
vollständiges Projekt in der Versionsverwaltung sowie einen Build,
der selbstständig und möglichst schnell durchläuft; als
Entwickler:in commitest und pushst du häufig kleine Änderungen. Mit
Jenkins oder vergleichbaren Werkzeugen erkennst du Fehler früh,
prüfst deinen Code auf einem separaten System und verringerst den
Aufwand vor einem Release. Aus meiner Ausbildungspraxis zeige ich
dir außerdem, wie du als IT-Azubi schrittweise einen CI-Server
aufbauen kannst, auf dem später auch Continuous Delivery oder
Continuous Deployment aufsetzen. Kapitelmarken [00:00:00] Einstieg
in Continuous Integration [00:01:47] Was Continuous Integration
bedeutet [00:04:46] Einfacher Einstieg mit einem automatisierten
Build [00:06:35] CI-Werkzeuge und Jenkins [00:10:03] Alle
Projektdateien in der Versionsverwaltung [00:10:59] Builds
automatisieren und passende Werkzeuge wählen [00:13:39] Schnelle
Builds für zeitnahes Feedback [00:14:49] Automatisierte Tests und
Legacy Code [00:15:56] Kleine Commits und neue Arbeitsgewohnheiten
[00:18:31] Erfolgreiche Builds und verfügbare Softwarestände
[00:19:20] Auf einem separaten System bauen [00:21:12] Zeit sparen
und Fehler leichter finden [00:22:34] Feedback im Team und
Codequalität [00:23:44] Den Projektstatus sichtbar machen
[00:24:15] Codekonventionen und typische Fehler prüfen [00:25:40]
Testabdeckung und Abhängigkeiten sichtbar machen [00:26:33] Aus
Codeprüfungen lernen und Trends verfolgen [00:28:10] Artefakte
automatisch im Repository ablegen [00:29:13] Testsysteme
automatisch aktualisieren [00:31:06] Branch-Strategien und
Feature-Toggles [00:32:27] Continuous Delivery und Continuous
Deployment [00:34:28] Einen CI-Server als IT-Azubi schrittweise
aufbauen [00:35:09] Aufwendige Abläufe häufiger ausführen und
automatisieren [00:36:00] Quellen und Vorträge zum Vertiefen
[00:37:14] Buchclubs und Newsletter [00:39:22] Fragen für die 100.
Episode [00:40:55] Elenas Projektarbeit als Beispiel [00:42:21]
Abschluss und Ausblick Inhalt Voraussetzungen Völlig unabhängig von
Programmiersprache oder Plattform. Theoretisch auch ohne separate
Software umsetzbar, aber einfacher mit etablierten Lösungen wie
Jenkins, Team Foundation Server, Travis CI, Teamcity oder
CruiseControl. Alle Artefakte (Code, Oberflächen, Konfiguration
usw.) müssen in der Versionsverwaltung liegen. Ein automatischer
Build des Projekts muss möglich sein (z.B. mit Gradle oder MS
Build). Der Build sollte möglichst schnell sein. Die Funktionalität
sollte mit automatischen Tests abgedeckt sein. Entwickler müssen
häufig - mindestens täglich - committen. Vorteile Das Projekt ist
jederzeit auf dem neusten Stand automatisiert baubar. Vermeidung
von "Works on my Machine". Vermeidung langer Integrationsphasen vor
Deployments. Erziehung der Entwickler zu kleinen Commits, sauberem
Code und automatisierten Tests. Projektbeteiligte bekommen
jederzeit kurzfristiges Feedback zum Projektstand. Statische
Codeanalyse ist möglich. Einhaltung von Code-Konventionen, z.B. mit
Checkstyle. Finden/Verhindern von Bugs, z.B. mit FindBugs.
Codeabdeckung durch Tests, z.B. mit JaCoCo. Visualisierung von
Abhängigkeiten, z.B. mit JDepend. Trends können erkannt werden.
Artefakte können automatisch im Repository abgelegt werden.
Automatisches Deployment in eine Testumgebung kann stattfinden.
Mögliche Erweiterungen Verschiedene Strategien für die
Versionierung möglich, z.B. Feature Branches oder Feature Toggles.
CI ist die Basis für Continuous Delivery und Continuous Deployment.
Literaturempfehlungen Für Jenkins gibt es inzwischen eine eigene
Konferenz, deren Videos größtenteils bei Confreaks verfügbar sind:
Jenkins User Conference. Links Permalink zu dieser Podcast-Episode
RSS-Feed des Podcasts Kontinuierliche Integration – Wikipedia
Continuous Integration Unterschiede zwischen Continuous
Integration, Continuous Delivery und Continuous Deployment -
Scrum.de CI-Server bei heise Developer Version Control Strategies
Zusammenfassung Was Continuous Integration bedeutet Wenn mehrere
Entwickler:innen gleichzeitig an einer Software arbeiten, müssen
ihre Änderungen zu einem gemeinsamen, lauffähigen Stand
zusammenkommen. Continuous Integration (CI) bedeutet, diesen Code
regelmäßig zu integrieren, beispielsweise täglich oder mehrfach am
Tag. Ein CI-Server holt den aktuellen Stand aus der
Versionsverwaltung und führt automatisierte Builds sowie Tests aus.
Dadurch erhältst du zeitnah Feedback zu deinen Änderungen. Kleine
Schritte erleichtern es, die Ursache eines Fehlers zu finden und
den Code wieder lauffähig zu machen. In mündlichen Prüfungen frage
ich Prüflinge auch danach, ob sie CI für ihr Projekt eingerichtet
haben. Welche Werkzeuge infrage kommen CI lässt sich unabhängig von
der Programmiersprache und der Plattform einsetzen. Für einen
einfachen Einstieg reicht ein Skript, das nach einem Commit oder
Push beziehungsweise nachts den aktuellen Code auscheckt und den
Compiler aufruft. Bei einem Fehler kann es eine E-Mail verschicken.
Fertige CI-Produkte übernehmen diese Aufgaben und bieten weitere
Funktionen. Beispiele sind Jenkins, Team Foundation Server, Travis
CI, TeamCity und CruiseControl. Travis CI wird als Werkzeug für auf
GitHub gehostete Projekte vorgestellt; Team Foundation Server
verbindet im Microsoft-Umfeld die Versionsverwaltung mit CI-Builds.
Ich arbeite seit Jahren mit Jenkins und baue damit Java- sowie
.NET-Projekte. Obwohl Jenkins selbst in Java geschrieben ist, kann
es Projekte in anderen Sprachen bauen. Plugins stellen passende
Funktionen bereit. Eigene Bash- oder PowerShell-Skripte lassen sich
ebenfalls einbinden. Was dein Projekt mitbringen muss Alle
benötigten Dateien liegen in der Versionsverwaltung Damit der
CI-Server dein Projekt bauen kann, braucht er Zugriff auf sämtliche
dazugehörigen Dateien. Zum Quellcode kommen beispielsweise
Konfigurationsdateien und Dateien für die Oberfläche hinzu. Bei
Webprojekten gehören auch Grafiken oder Icons dazu. Der Server muss
alles aus dem Repository beziehen können. Als Versionsverwaltung
kommen etwa Git oder Subversion infrage. Im Podcast werden außerdem
CVS und TFS genannt. Der Build läuft selbstständig Jeder
erforderliche Schritt muss automatisiert ausführbar sein. Je nach
Projekt gehört dazu, den Code zu kompilieren und Tests auszuführen.
Weitere Schritte können Webdateien zusammenfassen,
Konfigurationsdateien erzeugen oder benötigte Datenbankzustände
herstellen. Für viele Plattformen gibt es passende Build-Werkzeuge:
Java: Ant, Gradle oder Maven. .NET: MSBuild. Ruby on Rails: Rake.
Bei anderen Sprachen kann eigener Aufwand entstehen. Für Natural
von der Software AG musste ich den automatisierten Build selbst
aufbauen, weil die benötigten Möglichkeiten fehlten. Dazu gehörte,
den Compiler aus einem Skript heraus aufrufen zu können. Der Build
liefert schnell Feedback Wenn du nach einer Änderung innerhalb
weniger Minuten ein Ergebnis bekommst, kannst du direkt darauf
reagieren. Sekunden wären noch günstiger. Auch ein nächtlicher
Build liefert regelmäßig Hinweise zum Zustand des Projekts.
Automatisierte Tests prüfen das Verhalten Der Compiler prüft, ob
sich dein Code übersetzen lässt. Automatisierte Tests prüfen, ob er
sich bei den getesteten Fällen wie erwartet verhält. Für
aussagekräftiges CI-Feedback brauchst du deshalb solche Tests. Bei
bestehender Software können sie fehlen. Michael Feathers beschreibt
in Working Effectively with Legacy Code Legacy Code als Code ohne
automatisierte Tests. Änderungen an solchem Code sind schwer
abzusichern. Du commitest und pushst häufig kleine Änderungen Damit
der CI-Server früh prüfen kann, solltest du deine Änderungen
möglichst kleinteilig und mehrfach täglich ins gemeinsame
Repository übertragen. Kleine Commits machen Fehler überschaubar.
Dafür müssen Entwickler:innen gegebenenfalls ihre Arbeitsweise
ändern. Wenn du CI im Betrieb einführst, gehört auch dazu, diese
Gewohnheiten gemeinsam zu verändern. Einen Server einzurichten
deckt den technischen Teil ab; das Team muss anschließend
regelmäßig mit ihm arbeiten. Was CI im Projekt bringt Ein geprüfter
Softwarestand ist verfügbar: Den letzten erfolgreichen Build kannst
du beispielsweise für eine Vorabversion oder eine Vorführung
verwenden. Abhängigkeiten vom Entwicklungsrechner werden sichtbar:
Auf dem separaten CI-System fallen fehlende Bibliotheken oder fest
eingetragene lokale Pfade auf. Damit lässt sich prüfen, ob das
Projekt außerhalb deines eigenen Rechners gebaut werden kann. Der
Aufwand vor Releases sinkt: Häufiges Integrieren verteilt die
Arbeit auf kleine Schritte und spart Zeit, die sonst kurz vor der
Auslieferung für umfangreiche Merges anfällt. Fehler lassen sich
leichter zuordnen: Bei wenigen kleinen Änderungen kannst du
schneller erkennen, welcher Code den Build beschädigt hat. Der
Projektstatus ist sichtbar: In Jenkins können Entwickler:innen und
Vorgesetzte sehen, ob ein Build erfolgreich war. E-Mails
informieren über Fehler und die zuletzt eingegangenen Commits. Aus
meiner Praxis kenne ich auch den sozialen Effekt solcher Meldungen:
Wenn ein beschädigter Build im Team sichtbar wird, kümmern sich
Entwickler:innen zeitnah darum. Das fördert sorgfältiges Arbeiten
und automatisierte Tests. Code automatisch prüfen und daraus lernen
Zusätzliche Werkzeuge lassen sich bei jedem Build ausführen. Gerade
als IT-Azubi bekommst du dadurch konkrete Hinweise zu deinem Code:
| Werkzeug | Was es prüft oder sichtbar macht | | --- | --- | |
Checkstyle | Codekonventionen, etwa Zeilenlängen und Namen von
Variablen | | FindBugs oder PMD | Auffällige Codestellen,
beispielsweise offene Ressourcen oder leere Catch-Blöcke | | JaCoCo
| Welche Teile des Produktivcodes durch Unit-Tests ausgefüh
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.