Eine Einführung in die kontinuierliche Integration – Continuous Integration – gibt es in der zweiundneunzigsten Episode des Anwendungsentwickler-Podcasts.
Podcast: Play in new window | Download (Duration: 42:53 — 15.7MB)
Abonnieren: Apple Podcasts | Spotify | RSS
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
Kleine Anmerkung zur Plattformunabhängigkeit / Mächtigkeit des Jenkins:
Wir arbeiten (je nach Abteilung) mit C#, PHP, Java und Javascript, mit jeweils komplett verschiedenen Frameworks (ASP.NET, Hibernate, Symfony, Typo3, Spring, Magnolia, Angular, etc…), Buildtools (Bower, Maven, BuildIt) und Testssuites drunter (JUnit, NUnit, PHPUnit, Karma, Selenium,…).
Alle unsere Projekte laufen auf demselben Jenkins (verteilt auf verschiedene Build-Nodes). Meines Wissens gab es hier noch nie größere Probleme oder Konflikte.
Bei uns ist der Jenkins sogar so eingestellt, dass kurz nach jedem Commit der entsprechende Build angestoßen wird. Damit gibt es Projekte, die von frühs 8 bis abends 18 permanent immer wieder neu gebaut werden.
Zusammen mit der Policy „Check nix ein, das nicht funktioniert“, hat man so regelmäßig einen Release-fähigen Zustand.
Für einige Projekte haben wir inzwischen auch ein Continuous Delivery eingebaut, also dass automatisch ein Deployment mit getriggert wird.
Danke für die Ergänzung! Gut zu wissen, dass auch in der Praxis so viele verschiedene Plattformen über den Jenkins bedient werden.
Den Build nach jedem Push haben wir auch aktiviert. Dabei ist es halt nur wichtig, dass der Build recht flott läuft. Unser Hauptsystem braucht teilweise 30 Minuten. Das ist für „schnelles“ Feedback etwas langsam :-/ Aber die „normalen“ Java- und .NET-Projekte sind ratzfatz durch 🙂
30 Minuten sind bei uns die kleinen Projekte. „Mein“ aktuelles Projekt braucht ~ 1 1/2 h, unser längstes ~ 4 1/2.
Wobei man fairerweise dazu sagen muss, dass die langen Buildzeiten primär durch die GUI-Tests (Selenium) entstehen. Grad mal bei „meinem“ Projekt nachgesehen: Die Unittests dauern 11 Minuten, die GUI-Tests 1h 20 min.
Wie umfangreich sind denn die Projekte (insbesondere die kleinen)? Und wie viele Tests gibt es da?
@Christian
„Mein“ Projekt hat ~ 5200 Tests, davon ~ 4200 Unittests.
Eines unserer kleinsten hat ~500 Tests, wobei ich dort grad nicht sagen kann, wieviel davon Unittests sind.
EDIT: Ziemlich viele Tests fahren den Spring- oder Web-Context hoch, was die Zeiten auch nochmal massiv erhöht im Vergleich zu simplen JUnit-Tests.
Uhhh… ja, das kostet! Die Oberflächentests sind bei uns auch super langsam…