Was ist kontinuierliche Integration?

Kontinuierliche Integration (CI) ist eine Praxis in der Entwicklung, bei der Entwickler die Integration von Code in ein einziges Code-Repository automatisieren.

Ohne CI müssten die Entwickler ihre individuellen Codebeiträge zum Endprodukt manuell koordinieren und kommunizieren. Eine Nicht-CI-Umgebung bedeutet unnötigen bürokratischen Aufwand und erfordert eine aufwändige Synchronisierung, was die Situation komplexer macht, als sie sein müsste.

Nicht selten ist die Kommunikation zwischen dem Entwicklungsteam und dem Rest des Unternehmens, insbesondere den Bereichen Produkt und Technik, gestört. Aufgrund des Zeitaufwands und der Komplexität der Integration neuer Changes, die nicht in einem einzigen Repository oder an einem einzigen Ort gespeichert sind, lässt sich die Zeit, die von der Entwicklung bis zur Produkteinführung vergeht, kaum abschätzen.

Grafik, die die verschiedenen Faktoren der kontinuierlichen Integration veranschaulicht.

CI, CD und die kontinuierliche Auslieferung sind wichtige Bestandteile des Lebenszyklus von Softwareversionen, einschließlich DevOps-Prozessen.

Kontinuierliche Integration (CI)

In der Regel wird CI im Rahmen der agilen Softwareentwicklung eingesetzt. Organisationseinheiten können Aufgaben in einer Liste und einer Produkt-Roadmap zusammenstellen. Sobald die Aufgaben umrissen sind, werden sie an verschiedene Teammitglieder zur Bearbeitung weitergegeben. Die verschiedenen Codes werden dann in einem Mastercode-Repository zusammengeführt.

Kontinuierliche Bereitstellung (CD)

Die CD ist der zweite Teil des Prozesses. Dabei wird der Code in Pakete zusammengefügt, die dann den Benutzern zur Verfügung gestellt werden können. In diesem Prozessschritt werden in der Regel automatisierte Tools eingesetzt, die ein Artefakt generieren, das jederzeit für die Auslieferung an Endbenutzer bereit ist.

Kontinuierliche Auslieferung

In dieser letzten Phase des Prozesses, der kontinuierlichen Auslieferung, wird das Softwareprodukt automatisch den Benutzern zugestellt, was bedeutet, dass es die Integration und Bereitstellung erfolgreich durchlaufen hat. Bei der Automatisierung werden Skripte oder Tools verwendet, die das Softwareprodukt auf öffentliche Server oder andere Mittel zur öffentlichen Verteilung übertragen. In einer hochgradig automatisierten und gut verwalteten Umgebung erfolgen diese Auslieferungen automatisch, sobald das Produkt bereitgestellt ist (daher kontinuierlich). Für einige Teams oder Produkte kann die Auslieferung stattdessen zu bestimmten Zeiten oder nach Abschluss anderer Prozesse und Prüfungen erfolgen.

Skalierung

Der Abbau von Code-Bürokratie kann dazu beitragen, dass DevOps und agile Workflows effektiv und reibungslos funktionieren – von der Entwicklung neuer Codes bis zum Ende des Zyklus. CI kann einem Unternehmen bei der Skalierung helfen, wenn dadurch Abhängigkeiten beseitigt werden, die der Entwicklung einzelner Funktionen im Wege stehen. Selbst wenn ein Entwickler in einem Silo arbeitet, kann er dies in der Gewissheit tun, dass sein Code in den Rest des Code-Repositorys integriert wird.

Verbesserung der Feedbackschleife

Das Feedback zu Geschäftsentscheidungen wird beschleunigt. Dies hilft Produktteams, ihre Ideen zu testen und die Arbeit mithilfe iterativer Produktentwicklung zu vereinfachen. Changes sind schnell realisierbar, messbar und erfolgreich, und Bugs können zeitnah angegangen und korrigiert werden.

Bessere Kommunikation

Entwicklungsteams können besser kommunizieren und müssen Rechenschaft ablegen, was die Kommunikation in einem DevOps-Team verbessert. Teams haben die Möglichkeit, den von anderen Teammitgliedern geschriebenen Code einzusehen und zu kommentieren, was wiederum die Möglichkeit bietet, mit anderen Entwicklern an künftigem Code zusammenzuarbeiten.

Versionskontrolle

Der Code durchläuft eine Versionskontrollsoftware wie Apache Subversion oder Git, und der Commit-Verlauf des Softwarecodes wird festgeschrieben, sodass er bei Bedarf geändert werden kann.

Erstellung

Die Entwickler erstellen ihren Code und der Code wird durch das Versionskontrollsystem geleitet. Anschließend wird der Code zur Kompilierung an die Build-Phase zurückgegeben.

Tests und Staging

Die Software wird getestet, einschließlich der Unit-Tests, mit denen die einzelnen Komponenten der Software geprüft werden. Nach Abschluss der Tests beginnt die Staging-Phase, d. h. die Software ist bereit für die Bereitstellung im Staging-Prozess. Hier wird der Code vor der abschließenden Testphase gesichtet und finalisiert.

Automatische Tests

Im Anschluss an die Staging-Umgebung durchläuft die Software automatisierte Tests, die für die Software konzipiert sind. Sobald die Software die automatisierten Tests bestanden hat, wird sie in die Bereitstellungsphase überführt.

Bereitstellung

Nach Abschluss der automatisierten Tests wird die Software für die Produktion bereitgestellt. Treten während der Testphase oder der anschließenden Bereitstellung Fehler auf, wird die Software erneut der Versionskontrolle unterzogen und auf Fehler untersucht. Werden dabei Fehler festgestellt, erfolgt eine Korrektur.

Repository pflegen

Jedes Artefakt, das zum Erstellen eines Projekts benötigt wird, sollte in einem zentralen Code-Repository abgelegt werden. Dadurch können integrierte Änderungen beibehalten werden, anstatt einzelne Versionen gleichzeitig zu pflegen.

Build automatisieren

Im Idealfall genügt ein einziger Befehl, um ein System aufzubauen – einschließlich der Automatisierung der Integration und der Bereitstellung in einer produktähnlichen Umgebung. Es gibt viele Fälle, in denen das Skript Binärdateien kompiliert und gleichzeitig Webseiten, Verteilungsmedien, Statistiken und Website-Seiten generiert.

Selbsttests in den Build integrieren

Mit jedem Test soll bestätigt werden, dass er sich so verhält, wie es von ihm erwartet wird.

Jeder Commit wird an die Baseline gesendet

Die Wahrscheinlichkeit von widersprüchlichen Changes kann exponentiell reduziert werden, wenn alle Beteiligten regelmäßige Commits vornehmen. Durch die täglichen Commits können die Entwickler Probleme oder notwendige Changes im Code erkennen und diese kommunizieren – eine Woche aufgestauter Arbeit kann hingegen dazu führen, dass Probleme nicht erkannt werden oder überhandnehmen – ein täglicher Commit ist deshalb unerlässlich.

Jeder Commit sollte erstellt werden

Commits müssen mit der aktuellen Arbeitsversion gebaut werden, um zu überprüfen, ob sie korrekt funktionieren. In der Regel kommt die automatisierte kontinuierliche Integration (ACI) zum Einsatz, der Build kann aber auch manuell durchgeführt werden. ACI verwendet einen Daemon, der das Versionskontrollsystem auf Änderungen hin überprüft und dann den Build-Prozess automatisch ausführt.

Für schnelle Builds sorgen

Jeder Build sollte so schnell wie möglich erstellt werden, um Probleme bei der Integration zu vermeiden oder schnell zu erkennen.

Die Produktionsumgebung zum Testen klonen

Eine Testumgebung kann zu Fehlern in einem getesteten System führen, wenn sie in einer Produktionsumgebung bereitgestellt wird. Durch das Klonen der Produktionsumgebung lassen sich Fehler vermeiden, da sich eine Produktionsumgebung von einer Testumgebung unterscheiden kann. Bei einer separaten Staging-Umgebung muss es sich um eine skalierbare Version handeln, bei der die Zusammensetzung des Technologiestacks beibehalten und gleichzeitig die Kosten gesenkt werden.

Den Zugang zu den neuesten Ergebnissen erleichtern

Stakeholder und Tester müssen die Arbeit möglicherweise sehen, daher ist es am besten, Builds bereitzuhalten, um den Umfang der erforderlichen Nacharbeit zu verringern, wenn eine Funktion neu erstellt werden muss. Durch frühzeitige Tests kann außerdem verhindert werden, dass sich Fehler zu weit in den Prozess hineinziehen.

Alle Teammitglieder können die Ergebnisse sehen

Wenn ein Build nicht funktioniert, ist der Grund dafür normalerweise leicht zu finden. CI hilft einem Team dabei, die vorgenommenen Änderungen und das Teammitglied, das die Änderungen vorgenommen hat, zu identifizieren. Das fördert die Transparenz und Produktivität.

Die Build-Bereitstellung automatisieren

Die meisten CI-Systeme führen selbst nach Abschluss eines Builds noch Skripte aus. Es ist möglich, ein Skript zu schreiben, um die Anwendung auf einem Live-Testserver bereitzustellen, der für alle sichtbar ist. CI setzt voraus, dass die Software mit zusätzlicher Automatisierung für die Produktion bereitgestellt wird, um Regressionen oder Defekte zu vermeiden.

Testgestützte Entwicklung

Sobald ein Projekt in die CI-Pipeline aufgenommen wurde, empfiehlt es sich, die Testabdeckung ständig weiterzuentwickeln und zu verbessern. Jede neue Funktion, die ihren Weg durch die CI-Pipeline nimmt, sollte von Tests begleitet werden, um zu überprüfen, ob der neue Code wie erwartet funktioniert.

Pull-Anforderungen und Code

Pull-Anforderungen sind ein wichtiger Bestandteil von CI – die meisten Softwareentwickler arbeiten mit einem Pull-Anforderungs- und Code-Review-Prozess. Eine Pull-Anforderung ist eine hervorragende Gelegenheit, die CI-Pipeline zu starten, um die Schritte der automatischen Genehmigung zu durchlaufen. Die manuelle Freigabe wird ebenfalls zum Zeitpunkt der Pull-Anforderung hinzugefügt, wenn ein Nicht-Stakeholder eine Überprüfung des Codes durchführen kann. Dies gibt dem Nicht-Stakeholder die Möglichkeit, Änderungen zu identifizieren, die Pull-Anforderung zu genehmigen oder abzulehnen.

Optimierung der Pipeline-Geschwindigkeit

Die Optimierung der Ausführungsgeschwindigkeit der CI-Pipeline ist von zentraler Bedeutung, da es sich um einen häufig genutzten Prozess handelt. Verzögerungen im Workflow können bei immer neuen Releases, größer werdenden Codebases und wachsenden Teams zu Problemen führen. Messen Sie die CI-Pipeline ständig, um sicherzustellen, dass sie optimiert ist.

Eine schnellere CI-Feedback-Schleife bedeutet auch eine schnellere CI-Pipeline. Entwickler haben die Möglichkeit, Änderungen voranzutreiben und mit der Benutzer-Experience zu experimentieren, Fehler schnell zu beheben und die Ausführungsgeschwindigkeit zu erhöhen, um Vorteile gegenüber der Konkurrenz und eine insgesamt höhere Qualität zu gewährleisten.

Bei der Erstellung von Anwendungen auf der ServiceNow-Plattform können Sie CI/CD nutzen. Sie können auch Ihre CI/CD-Tools mit dem DevOps-Produkt von ServiceNow verbinden, um die durch die CI/CD-Pipeline fließenden Vorgänge mit den Vorgängen zu verknüpfen, die in ServiceNow verwaltet werden. Das ServiceNow DevOps-Produkt kommt dem CI/CD-Prozess in vielerlei Hinsicht zugute, unabhängig davon, ob Sie auf der ServiceNow-Plattform oder außerhalb von ServiceNow in Tools wie Azure DevOps, GitLab oder Jenkins einen Build erstellen.

Bessere Zusammenarbeit

Verwalten Sie Code-Changes effektiv für mehrere Entwickler, wenn Sie die Git-Repository-Integration nutzen und eine Verbindung zwischen Arbeitselementen wie User Storys und den Commits im Repository erstellen. Mit der zusätzlichen Verbindung von Commits zu Testergebnissen und Changes in ServiceNow erhalten Sie eine vollständige End-to-End-Sicht auf die Pipeline.

DevOps optimieren

Automatisieren Sie die Erstellung, Genehmigung und Bereitstellung von Changes und schreiten Sie schneller und effizienter von der Entwicklung über die Tests bis zur Produktion voran.

Schnellere Entwicklung

Stellen Sie Anwendungen schneller bereit, um Teams zu helfen, frühzeitig und möglichst oft auf Feedback zu reagieren.

Den Wertstrom verwalten

Erstellen Sie Berichte über die gesamte Pipeline oder den Wertstrom von der Idee bis zur Produktion. Kommunizieren Sie teamübergreifend, vergleichen Sie die Leistung verschiedener Tools und ermitteln und beheben Sie Engpässe.

Fähigkeiten, die mit Ihrem Geschäft wachsen

Weiten Sie den DevOps-Erfolg auf das gesamte Unternehmen aus. Verringern Sie die Risiken, die ein schnelles Tempo mit sich bringt, und minimieren Sie die Reibung zwischen IT-Betrieb und Entwicklung.