Continuous Integration ist die erste Hälfte des Akronyms CI/CD. Continuous Delivery stellt die zweite Hälfte dar. In diesem dreiteiligen Artikel schauen wir in die beiden Hälften von CI/CD, um zu verstehen was sie bedeuten und welchen Zweck sie haben. Im dritten Teil wirst Du dann sehen wie Du Uptrends in Deine CI/CD Prozesse implementieren kannst, um einen möglichst großen Mehrwert zu generieren. Lass uns mit Continuous Integration beginnen.
Was ist Continuous Integration?
Continuous Integration (CI) ist ein Prozess, der speziell im Bereich der Softwareentwicklung eingesetzt wird, um Software schnell und effizient zu entwickeln. Der Softwareentwickler bricht hierbei zu Beginn der Planung die gewünschte Funktionalität in kleine logische Einheiten herunter. Ist die Planung abgeschlossen, wird der Code geschrieben und gleichzeitig auf dem Computer des Entwicklers getestet. Ist das Ergebnis zufriedenstellend, prüft der Entwickler den Code innerhalb eines Versions-Kontroll-Systems. Hierbei werden durch den Code Check-In automatische Prozesse gestartet, die die Änderungen in einen neuen Build einfügen und Schritt-für-Schritt die Software testen. Ist der Code implementiert, beginnt der Zyklus von vorne mit einer neuen Planungsphase.
Warum Continuous Intergration verwenden?
Der Hauptgrund für die Nutzung von Continuous Intergration ist die hohe Geschwindigkeit von der Planungsphase bis zur Auslieferung neuer Software, und der damit verbundenen Zeitersparnis. Frühere Prozesse zur Softwareentwicklung erforderten, dass Softwareentwickler über größere Zeitspannen isoliert voneinander tätig waren. Der Code wurde von Entwicklern anhand von Design Specs geschrieben. Dieser Code wurde dann erst in einem deutlich späteren Teil des Prozesses in Verbindung mit dem Code der anderen Entwickler getestet. In der Realität wurde also erst einmal über Monate oder gar Jahre Code entwickelt, um diesen dann in einem teilweise noch längeren Prozess der Bugfixes, Code Revisions und Korrektur von Funktionalitäten die einzelnen Bausteine zusammen zu setzten. Nach all diesem Aufwand war es dann noch notwendig, weitere Regression-Tests durchzuführen. Bis zu diesem Zeitpunkt hat der Kunde die Software noch nicht einmal sehen, geschweige denn abnehmen können. Eine solche Arbeitsweise ist weder effizient, noch dazu angetan Zustimmung bei den Kunden zu erhalten.
Warum also CI nutzen? CI liefert dem Nutzer besseren Code innerhalb deutlich kürzerer Zeit, da Fehler im Code Design, Probleme mit Code und Systemintegration sowie Performance Probleme bereits im Produktionsprozess offengelegt werden und als Information an die Entwickler in einem kontinuierlichen Loop zurückgehen.
Wie beschleunigt Continuous Integration den Entwicklungsprozess?
Wie bereits oben beschrieben, wenn Entwickler in isolierten Umgebungen Code entwickeln, ist dessen Integration in eine Gesamtlösung in der Regel mit erheblichem Aufwand verbunden. Das Identifizieren von Fehler ist zeitaufwendig. Das Beheben dieser Fehler kann dann wiederum zu weiteren Konflikten in der Software führen, und zusätzlichen Störungen in anderen Bereichen der Lösung, wo man sie gar nicht erwartet hat. Der Integrationsprozess dauert länger als der eigentliche Produktionsprozess. Das ist teuer, ineffektiv und verzögert die Auslieferung des Produkts.
Wird CI genutzt, können mehrere Entwickler oder mehrere Entwicklerteams nach Use Cases oder User Stories arbeiten. Ein Use Case oder eine User Story beschreibt einen Block an Funktionalität. Das kann zum Beispiel das Hinzufügen eines Artikels zu einem Shopping Cart sein. Die Entwickler programmieren den Code und testen das neue Feature in der lokalen Kopie der Entwicklungsumgebung. Ist dieser Schritt erfolgreich abgeschlossen, testen sie den Code in einem Version-Control-System wie Git. Durch die Aktion des Code Check-Ins werden automatisierte Prozesse angestoßen, die den neuen Code in die bestehende Applikation integrieren. Weitere automatische Prozesse übernehmen die Tests der neuen Funktionalität. Gleichzeitig können sich die Entwickler schon neuen Use Cases zuwenden oder weiter an dem neuen Code arbeiten.
Mit CI wird mehr Zeit für das Entwickeln neuer Features als für die Beseitigung von Fehlern verwendet. Die kürzeren Entwicklungsschleifen führen zu früheren Fertigstellungsterminen und stabileren Produkten.
Ein Beispiel für Continuous Integration
Um uns den Prozess der CI zu verdeutlichen, schauen wir uns diesen anhand eines Beispiels an, einer Kalender App zur Vereinbarung von Terminen. Aktuell können Nutzer in unserer Beispiel-Applikation einen Termin mit Datum und Uhrzeit vereinbaren. Aber in der App gibt es keine Option, den Termin abzusagen oder zu verschieben. Unser Ziel ist es, diese Funktion in die App zu integrieren. Der Lead Entwickler entscheidet, du entwickelst den Code für die Funktion der Absage, ein weiterer Entwickler übernimmt die Funktion der Terminverschiebung. Und so sieht der Prozess aus:
- Du kopierst die Applikation von der aktuellen Versioning Plattform auf deinen Computer.
- Du schreibst den neuen Code. Dieser Teil der neuen Funktionalität beinhaltet in der Applikation einen neuen Button oder Link, den der User benutzt, um den Termin zu löschen. Nachdem der Nutzer die Absage des Termins bestätigt hat, stellt eine neue Funktion sicher, dass ein Request an die Datenbank gesendet wird, der den Termin aus dem Kalender entfernt.
- Dieser Teil des Codes wird sorgfältig in der lokalen Kopie der Applikation getestet.
- Danach bestätigst Du die Änderungen an das Versioning System. Dort werden automatisierte Entwicklungs- und Test-Prozesse angestoßen.
- Ist der Prozess abgeschlossen, werden die Ergebnisse auf Fehler untersucht. Gibt es keine Fehler, wird zum nächsten Schritt übergegangen. Gibt es Fehler, wird der Code überarbeitet. In unserem Beispiel hat ein anderer Entwickler parallel zu Dir das User Interface überarbeitet. Er hat die Position eines bestehenden Buttons versetzt. Du hast den Button für die Absage des Termins an derselben Stelle positioniert. Aufgrund dieses Konflikt kommt es zu einem Fehler in dem Build. Du überarbeitest die Position des Buttons und startest dann erneut mit dem Testprozess.
- Die Arbeit an dieser Funktionalität ist abgeschlossen und du beginnst die Arbeit an einem neuen Use Case oder du arbeitest weiter an dieser Funktionalität.
Du hast die Applikation um ein wichtiges Feature erweitert und es ist gerade erst Mittag. Der neue Code ist bereits Teil der Applikation, zumindest in der aktuellen Version der Entwicklungsumgebung.
Der Lead Entwickler hatte Mia, eine Kollegin von dir, beauftragt, den anderen Teil der neuen Funktionalität zu entwickeln. Für das Verschieben eines Termins benötigt sie zwei Schritte. Im ersten Schritt löscht sie den Termin, um dann die Daten in der Datenbank mit den neuen Daten zu aktualisieren. Mia entwickelt also diese Feature und aktualisiert hierbei ebenfalls das User Interface. Was im Hintergrund tatsächlich passiert, Mias` neue Funktion greift auf den von dir entwickelten Code zur Löschung eines Termins zurück. Im nächsten Schritt wird mit der bereits bestehenden Funktion, einen Termin zu erstellen, der Eintrag des neuen Termins in die Datenbank durchgeführt.
In kürzester Zeit hast Du neuen Code entwickelt, der dann wiederum für eine weitere Entwicklung von Mia verwendet wurde. Mit minimalem Zeitaufwand konntet ihr so die Applikation um mehrere wertvolle Features erweitern.
Automation ist Key
Die agile Entwicklungsumgebung ist dynamisch. Änderungen finden innerhalb kürzester Zeit statt und Continuous Integration ist ein wichtiger Teil des Entwicklungsprozesses. Dabei steht die Automatisierung von Entwicklung und Test der Software im Mittelpunkt von CI. Bei der Entwicklung von Webseiten, Web Applikationen und APIs ist es wichtig, Tests in Bezug auf Funktionalität, Performance und Verfügbarkeit durchzuführen.
Uptrends kannst du auch hinter der Firewall nutzen, um deine Entwicklungsumgebung zu überwachen. Die Uptrends´ Private Checkpoints werden auf Servern innerhalb deiner Infrastruktur installiert. Damit ist es möglich, die Development Umgebung auf die gleiche Art und Weise wie von außen zugängliche Webseiten und Service zu überwachen. Damit kannst du die API Monitore und Web Applikation Überwachungen parallel zu deiner sich verändernden Applikation anpassen. Wenn du dann bereit bist für ein Deployment der neuen Applikation in deiner Live Umgebung, kannst du parallel die neuen oder modifizierten Monitore für deine Produktiv-Umgebung launchen (hierzu später mehr).
Nächster Teil: Continuous Delivery (in Kürze verfügbar)
