Continuous Integration

Was ist Continuous Integration?

Continuous Integration (CI) kann als Alternative zum Feature Branching betrachtet werden. Einfach ausgedrückt, erfolgt dieser Prozess, wenn Teams kontinuierlich ihren Code in den gemeinsamen Branch oder die Mainline integrieren, was sofortiges Feedback ermöglicht.

In diesem Fall ermöglicht trunk-basierte Entwicklung Continuous Integration oder mit anderen Worten, sie ermöglicht Teams, kleine Änderungen häufiger in den Hauptcode oder den Trunk zu integrieren, möglicherweise mehrmals täglich.

Trunk-basiertes Development gibt Developern im Wesentlichen die Mittel, ihre Arbeit in kleine Batches zu unterteilen und ihre Arbeit mindestens einmal täglich in den Trunk oder die Mainline zu integrieren. Dagegen kann Feature Branching Tage oder Wochen in Anspruch nehmen, da Developer Änderungen an langlebigen Branches vornehmen und diese nicht integrieren, bis ein Feature abgeschlossen ist. Build-Automatisierung ist eine der wichtigsten Voraussetzungen für Continuous Integration. Jede Integration eines Developers wird durch einen automatisierten Build verifiziert, um Fehler zu erkennen. Ein Build-Werkzeug übernimmt also die automatisierte Bereitstellung der Software. Jeder Commit, jede Freischaltung eines Developers sollte eine Reihe von automatisierten Tests auslösen, um die Qualität des Codes sicherzustellen. Diese automatisierten Tests sollten anzeigen, dass deine Software wie vorgesehen funktioniert. Es gibt eine Vielzahl von Tools, aus denen du je nach Bedarf wählen kannst, darunter Jenkins, Travis CI, Circle CI, TeamCity und CodeShip.

Vorteile von CI

Schnellere Bereitstellung

Diese Technik ermöglicht es Developern, schnell zu agieren. Im Gegensatz zu Feature Branches ist der Master Branch im trunk-basierten Development der einzige langlebige Branch, während alle anderen Branches eine begrenzte Lebensdauer haben, was Merge-Konflikte reduziert, da keine Branches zu lange in der Entwicklung bleiben. Es ermöglicht auch schnelleres Feedback, fast sofort, was die Transparenz erhöht. Kein wochenlanges Warten, bis Developer ihre Änderungen von einem privaten Branch integrieren.

Risikominderung

Wenn Developer kontinuierlich ihre Änderungen in die Mainline integrieren, ist es einfacher und schneller, Bugs zu erkennen und aus deinem Code zu entfernen. Daher sind deine Chancen, ein stabileres Feature mit weniger Bugs zu veröffentlichen, höher. Das führt zu einem weit besseren Produkt, das immer bereit zur Veröffentlichung ist. Es reduziert auch das Risiko, langlebige Branches zu mergen, was zu Konflikten und zur sogenannten „Merge Hell“ führt.

Höhere Qualität der Releases

Continuous Integration ist unerlässlich, wenn du neue Features schnell freigeben und kleine Änderungen vornehmen möchtest während die sogenannte „Merge Hell“, die oft bei langlebigen Branches auftritt, minimiert wird. Wie bereits erwähnt, können mit Continuous Integration Bugs viel schneller erkannt werden, da kontinuierliche Änderungen stattfinden, was zu erhöhter Effizienz und Produktivität führt.

Das bedeutet, die Qualität wird erheblich verbessert, Änderungen werden kontinuierlich vorgenommen und du musst nicht warten, bis alle fertig sind, um deine Änderungen zu integrieren. So kannst du deinen Code häufiger überprüfen, was zu größerem Vertrauen bei der Freigabe deiner neuen Features führt.

Nachteile von Continuous Integration

Die größte Herausforderung bei dieser Praxis ist, dass aufgrund der häufig vorgenommenen Änderungen Developer möglicherweise gleichzeitig versuchen, ihren Code zu integrieren, was zu längeren Wartezeiten führen kann. Auch ist ständige Überwachung notwendig, um eventuelle Probleme schnell beheben zu können. Nichtsdestotrotz ist sie sicherlich nützlich, wenn du neue Produkte schnell und sicher freigeben möchtest.

Continuous Integration und Continuous Delivery vs. Continuous Deployment

Die Begriffe Continuous Integration und Continuous Delivery werden oft zusammen verwendet. Tatsächlich gehen die beiden Hand in Hand, wobei sie oft zusammen als „CI/CD“ bezeichnet werden.

Für die kontinuierliche Auslieferung benötigst du Continuous Integration. Continuous Delivery ermöglicht die automatisierte Bereitstellung des integrierten Codes vom Entwicklungs- zum Produktionsstadium.

Mit Continuous Delivery bereitest du die Freigabe zur Bereitstellung auf einer häufigen Basis vor. Daher wird der Code mehrmals täglich geliefert. Sie ist dafür verantwortlich, den Code zu testen und sicherzustellen, dass er ohne Bugs oder Verzögerungen ausgeführt wird. Dazu werden Änderungen einer ausgewählten Anzahl von Usern zur Verfügung gestellt, um Feedback zu erhalten, bevor diese Änderungen für alle User ausgerollt werden.

Daher repräsentiert CI/CD den Prozess der kontinuierlichen Entwicklung, des Testens und der Bereitstellung neuer Releases. Die letzte Stufe von CI/CD ist Continuous Deployment, oft mit Continuous Delivery verwechselt.

Continuous Deployment bedeutet jedoch, dass alle Änderungen, die am Code vorgenommen werden, automatisch in die Produktion übertragen werden, während Continuous Delivery das Feature zur Freigabe in die Produktion vorbereitet. Dabei wird der Zeitpunkt nicht automatisch bestimmt, sondern vom Team festgelegt. Zusammen genommen machen all diese Praktiken jede Freigabe zu einem viel weniger riskanten Unterfangen.

CI und Feature Flags

Es kann vorkommen, dass ein Developer seine Änderungen abgeschlossen und in die Mainline integriert hat, während die Arbeit eines anderen Developers noch nicht abgeschlossen ist. Ein Problem entsteht, wenn das Feature nicht freigegeben werden kann, bis alle Developer ihre Änderungen abgeschlossen haben. Es kommt zu Verzögerungen im Integrationsprozess. Hier kann der Konflikt gelöst werden, indem alle Änderungen, einschließlich der unvollständigen, gemergt werden, jedoch ohne die halb-fertigen Änderungen offenzulegen. Dies kann durch die Verwendung von Feature Flags erreicht werden.

Sie schalten Teile des Codes ein oder aus, das heißt, das Feature wird deaktiviert, wenn es unvollständig ist. Sie platzieren diese unvollständigen Änderungen im Wesentlichen hinter einem Flag, bis es bereit zur Freigabe ist. Dann, sobald diese Änderung fertig ist, kann sie mit einem einfachen Klick aktiviert werden. Daher hilft die Verwendung von Feature Flags in einem solchen Szenario, den Branch gesund zu halten.

Abschließende Gedanken und Best Practices

Continuous Integration ermöglicht häufige Bereitstellungen. Damit kannst du deine Releases schneller an deine User bringen und mehr Feedback zu diesen Features erhalten. Es erleichtert auch den Kollaborationsprozess zwischen Developern, steigert die Produktivität und die Qualität ihrer Releases.

Wir beenden diesen Artikel mit einigen Best Practices für CI, um zu überprüfen, ob dein Team wirklich CI praktiziert. Diese Liste stammt aus einem umfassenden Artikel von Martin Fowler zu CI:

• Pflege eines einzigen Quell-Repositorys
• Automatisierung des Build
• Selbsttestender Build
• Tägliche Integration in die Baseline
• Konstruktion jedes einzelnen Commits
• Sofortige Reparatur defekter Builds
• schneller Build
• Test in einer Klonversion der Produktionsumgebung
• Einfache Bereitstellung des neuesten ausführbaren Programms
• Transparenz
• Automatisierung der Bereitstellung