Bei Continuous Integration (C)) handelt es sich um einen Softwareentwicklungsprozess, bei dem die Entwickler den neu geschriebenen Code im Laufe des Entwicklungszyklus häufiger integrieren und ihn mindestens einmal täglich zur Codebasis hinzufügen. Für jede Iteration des Builds werden automatisierte Tests durchgeführt, damit Integrationsprobleme früher erkannt werden können, wenn sie noch vergleichsweise einfach zu beheben sind. Dadurch können auch Probleme beim abschließenden Zusammenführungsprozess für die Freigabe vermieden werden. Continuous Integration hilft bei der Optimierung des gesamten Erstellungsprozesses, was zu einer höheren Qualität der Software und zu besser kalkulierbaren Bereitstellungsterminen führt.

DevOps bezeichnet per definitionem sowohl einen Softwareentwicklungsprozess  als auch einen Wandel in der Unternehmenskultur, der die Bereitstellung qualitativ hochwertigerer Software  beschleunigt, indem die Leistungen der Teams in der Softwareentwicklung und im IT-Betrieb automatisiert und integriert werden – also von zwei Gruppen, die üblicherweise getrennt voneinander oder in Silos gearbeitet haben.

In der Praxis gehen die besten DevOps-Prozesse und -Kulturen über die Entwicklung und den Betrieb hinaus. Sie beziehen die Beiträge aller an der Anwendung Beteiligten – einschließlich Plattform- und Infrastruktur-Engineering, Sicherheit, Compliance, Governance, Risikomanagement, Geschäftsleitung, Endbenutzer und Kunden – in den Lebenszyklus der Softwareentwicklung mit ein.

Im DevOps-Framework steht Continuous Integration ganz am Anfang des Softwareentwicklungsprozesses. Dabei wird Code mindestens einmal täglich eingecheckt, um zu verhindern, dass die lokalen Kopien zu stark vom Hauptzweig des Code-Builds abweichen. Auf diese Weise lassen sich katastrophale Konflikte bei der Codezusammenführung (Merge) vermeiden, durch die der Build unbrauchbar („kaputt") gemacht werden kann und deren Beseitigung das Team Stunden oder womöglich Tage kostet.

Continuous Integration fungiert als Voraussetzung für die Test-, Bereitstellungs- und Freigabephasen der kontinuierlichen Bereitstellung. Das gesamte Entwicklungsteam kann binnen weniger Minuten nach dem Einchecken bereits erkennen, ob Sie fehlerhaften Code erstellt haben, da der Service für Continuous Integration automatisch Builds Ihrer Codeänderungen erstellt und diese auf Fehler testet.

Continuous Delivery und Continuous Deployment folgen im DevOps-Zyklus auf Continuous Integration. 

Continuous Delivery (CD) knüpft dort an, wo Continuous Integration endet, und automatisiert die Bereitstellung von Anwendungen in ausgewählten Infrastrukturumgebungen. CD konzentriert sich darauf,  alle validierten Änderungen an der Codebasis – Aktualisierungen, Korrekturen von Programmfehlern und sogar neue Funktionen – so schnell und sicher wie möglich an die Benutzer weiterzugeben. Es sorgt dafür, dass Codeänderungen automatisiert in verschiedene Umgebungen übertragen werden, z. B. in eine Entwicklungs-, eine Test- bzw. eine Produktionsumgebung.

Bei der kontinuierlichen Bereitstellung werden die Codeänderungen für eine Anwendung automatisch in der Produktionsumgebung freigegeben. Diese Automatisierung wird durch eine Reihe vordefinierter Tests gesteuert. Sobald neue Aktualisierungen diese Tests bestehen, überträgt das System die Aktualisierungen direkt an die Benutzer der Software.

Zu den häufig genannten Vorteilen der Continuous Integration gehören die folgenden:

• Frühe Fehlererkennung und Metriken, die eine frühzeitige Fehlerbehebung ermöglichen, manchmal schon innerhalb weniger Minuten nach dem Einchecken
  
  
• Kontinuierlicher und nachgewiesener Fortschritt für verbessertes Feedback
  
  
• Verbesserte Zusammenarbeit im Team; jedes Teammitglied kann Änderungen am Code vornehmen, den geänderten Code in das System integrieren und Konflikte mit anderen Teilen der Software innerhalb kurzer Zeit bestimmen
  
  
• Verbesserte Systemintegration, wodurch Überraschungen am Ende des Softwareentwicklungszyklus vermieden werden
  
  
• Weniger parallele Änderungen für das Zusammenführen und Testen
  
  
• Geringere Anzahl von Fehlern bei Systemtests
  
  
• Fortlaufend aktualisierte Systeme, für die Tests durchgeführt werden können

Agiles Arbeiten bezeichnet ein Verfahren in der Softwareentwicklung, das die Art und Weise verbessert, wie sich Softwareentwicklungsteams intern selbst organisieren, sich an geänderte Anforderungen anpassen und Softwarereleases veröffentlichen. Da kontinuierliche Integration (Link befindet sich außerhalb von IBM) und agile Entwicklung viele Merkmale (z. B. Testautomatisierung) gemein haben, kann es sinnvoll sein, nicht getrennt von Continuous Integration und agiler Entwicklung zu sprechen. Die agile Entwicklung organisiert die Entwicklung in kleinere Gruppen von Arbeitsaufgaben oder Sprints. Bei ihrer Anwendung in DevOps hilft der kombinierte Einsatz dieser Methoden, die Qualität der Software und die Flexibilität des Projekts sicherzustellen.

Continuous Integration erfordert die häufige Integration von Arbeit, oft mehrmals am Tag. Die Integration wird dann mithilfe eines automatisierten Builds überprüft, der Integrationsfehler so früh wie möglich erkennt. Der Build sollte Laufzeittests als Teil der Überprüfung enthalten. Die logische und natürliche Konsequenz der Ausweitung von Schnelltests auf Laufzeittests in einer automatisierten Testumgebung ist Continuous Delivery.

Agile Entwicklung (Link befindet sich außerhalb von IBM) ist ebenfalls iterativ und passt sich an Änderungen an, sodass Lösungen im Laufe der Zeit skaliert und weiterentwickelt werden können. Im Kontext der kontinuierlichen Integration geht es bei der agilen Softwareentwicklung darum, Softwareiterationen basierend darauf bereitzustellen, wie die Features bei der kontinuierlichen Integration jeweils priorisiert werden.

Zu den beliebten Open-Source-Tools für Continuous Integration zählen unter anderem die folgenden:

• Jenkins: Dieses weit verbreitete Open-Source-Tool fürContinuous Integration ermöglicht Entwicklern, Code automatisch zu erstellen, zu integrieren und zu testen, sobald er im Quellcoderepository per Commit festgeschrieben worden ist, wodurch es für Entwickler einfacher wird, Programmfehler in einem frühen Stadium zu erkennen und Software schneller bereitzustellen. Auf Jenkins ist das Docker-Plug-in verfügbar.
  
  
• Buildbot: Mit Buildbot können alle Aspekte des Softwareentwicklungszyklus automatisiert werden. Als Job-Planungssystem stellt er Jobs in die Warteschlange, führt sie aus und meldet die Ergebnisse zurück.
  
  
• Go: Was Go von der Masse abhebt, ist das Konzept der „Pipelines", wodurch sich die Modellierung komplexer Build-Workflows einfacher gestaltet.
  
  
• Travis CI: Travis CI ist eine der ältesten und vertrauenswürdigsten gehosteten Lösungen und ist auch als On-Premises-Version für Unternehmen verfügbar.
  
  
• GitLab CI: Als integraler Bestandteil des Open-Source-Projekts „Rails" ist GitLab CI ein kostenloser gehosteter Service, der eine detaillierte Verwaltung des Git-Repositorys mit Funktionen wie Zugriffssteuerung, Fehlerverfolgung, Codeüberprüfung und vielem mehr bietet.

Continuous Integration mithilfe von Open-Source-Tools bietet unter anderem die folgenden Vorteile:

• Hunderte von Plug-ins, die Ihr Projekt unterstützen können
  
  
• Breite Unterstützung für Open-Source-Sprachen wie Python, Java und JavaScript
  
  
• Kostenlos, wodurch Studenten, Startups und Entwicklern, die nebenbei arbeiten, ein leistungsfähiges Tool an die Hand gegeben wird, das zugleich das Budget schont
  
  
• Anpassungsfähigkeit, die ermöglicht, dass Entwickler die Basis eines CI-Tools übernehmen und auf dieser dann aufbauen können, um sie an die entsprechenden Bedürfnisse anzupassen
  
  
• Die Fähigkeit, die Tools zu modifizieren und weiterzuverteilen

Zu den Open-Source-Tools für Continuous Integration, die Sie für Ihren Softwareentwicklungs-Workflow in Betracht ziehen sollten, gehören Jenkins, Go, Buildbot und Travis CI, über die Sie im nächsten Abschnitt nachlesen können.

Ein Server für Continuous Integration (CI-Server) ist ein Softwaretool, das alle Vorgänge der kontinuierlichen Integration bündelt und eine zuverlässige, stabile Plattform für die Erstellung Ihrer Projekte bietet. Sie können CI-Server konfigurieren und anpassen, um verschiedene Projekte für verschiedene Plattformen zu erstellen. Ein Server für Continuous Integration modelliert und visualisiert komplexe Workflows (ermöglicht also die kontinuierliche Bereitstellung) und stellt eine intuitive Schnittstelle für die Erstellung kontinuierlicher Lieferpipelines dar. Ein CI-Server bietet die Funktionalität für Folgendes:

• Ausführen automatischer Builds, Tests und Releases an einem einzigen zentralen Ort
  
  
• Bereitstellen jeder beliebigen Version zu jedem beliebigen Zeitpunkt
  
  
• Sicherstellen einer geordneten Strukturierung der Konfiguration
  
  
• Unterstützen von Plug-ins zur Erweiterung der Funktionalität
  
  
• Überwachen des Repositorys Ihres Projekts
  
  
• Extrahieren von Änderungen und Ausführen von Aufgaben, die Sie für eine erfolgreiche Festschreibung (Commit) definiert haben
  
  
• Senden von Feedback an die betreffenden Projektmitglieder mit Details des Builds

Der folgende – hypothetische – Anwendungsfall veranschaulicht, wie zwei Softwareentwickler die Continuous Integrationn nutzen können, um ihren DevOps-Prozess zu verbessern.

Die beiden Entwickler müssen sich gegenseitig darüber informieren, welche Features funktionieren und wie sie funktionieren. Dieses kleine Team benötigt regelmäßige Updates und muss in der Lage sein, seinen Code als Ganzes zu integrieren und zu testen. Die Terminierung von Code-Check-ins und -Tests nehmen viel Entwicklungszeit in Anspruch. Es wird ein automatisiertes System für Continuous Integration benötigt.

Das Aushandeln, wann diese Kombinationen und Tests stattfinden sollen, würde viel Zeit der Entwickler verschlingen. Sie müssten bei den folgenden Punkten jeweils eine Einigung erzielen:

1. Wann soll mit dem Testen der Codeintegration begonnen werden?
2. Wie soll getestet werden, ob die Integration erfolgreich verlaufen ist?
3. Wie sollen die Ergebnisse an das Team weitergegeben werden?

Plattformen für Continuous Integration verfügen über Standardantworten auf diese Fragen und ermöglichen in den meisten Fällen auch das Konfigurieren und Einrichten.

CI-Plattformen wie Jenkins beginnen mit Integrationstests normalerweise beim Einchecken. Wenn neuer Code eingecheckt wird, führt das CI-System eine Reihe von Tests durch, die u. a. Komponententest und Regressionstests umfassen können, und ermittelt anschließend, ob der Code erfolgreich integriert wurde.

Bei Verwendung einer kompilierten Sprache wird standardmäßig geprüft, ob der Code erfolgreich kompiliert wurde. Wenn dies nicht der Fall ist, hat der neue Code den Build zerstört. Für Sprachen wie Python oder JavaScript müssen Sie eigene Integrationstests erstellen.

Die meisten CI-Systeme protokollieren aber in jedem Fall die Integrationsversuche, die Erfolgsrate und andere Metriken.

Die Bedeutung des Testens

Kontinuierliches Testen beginnt, wenn Sie einen Build und ein Paket („installierbare Entität" oder „paketierte Entität") für Continuous Integration erstellen. Die Tests werden gestoppt, wenn das verpackte Element in die Produktion geht. Jeder Schritt dieses Vorgangs von Anfang bis zum Ende bezieht eine Testsuite ein.

Wenn nur eine Testphase ansteht, entfallen mindestens 30 Prozent der Continuous Integration auf Tests. Realistischerweise macht das Testen jedoch 50 Prozent bis 70 Prozent der Aktivitäten in der kontinuierlichen Integration aus. In der Vergangenheit musste das Testen manuell durchgeführt werden. Heutzutage können Sie automatisierte Tests einsetzen – und diese sind der Schlüssel zu einer erfolgreichen kontinuierlichen Integration.

Im Rahmen der Automatisierung von Tests für Continuous Integration wird bei der testgesteuerten Entwicklung iterativ Code erstellt und ein Anwendungsfall nach dem anderen getestet, um die Testabdeckung sicherzustellen, die Codequalität zu verbessern und die Grundlage für die Continuous Delivery zu schaffen. Automatisierte Tests zeigen Ihnen, ob einer oder mehrere der Tests für neuen Code, die in allen Funktionsbereichen der Anwendung entwickelt wurden, fehlgeschlagen ist bzw. sind. Die Best Practice erfordert, dass Entwickler alle oder eine Untergruppe von Tests in ihren lokalen Umgebungen ausführen müssen, wodurch sichergestellt wird, dass Entwickler nur Quellcode zur Versionskontrolle festschreiben, nachdem die neuen Codeänderungen ihre Tests bestanden haben. Die Erfahrung zeigt, dass die Durchführung effektiver Regressionstests dabei helfen kann, unliebsame Überraschungen zu einem späteren Zeitpunkt zu vermeiden.

Die Pipeline für Continuous Integration

In einer Pipeline für Continuous Integration werden die Abschnitte (Stages) in der Pipeline eines Projekts, wie Builds, Tests und Bereitstellungen, auf wiederholbare Weise und mit minimalem menschlichen Eingriff automatisiert. Eine automatisierte Pipeline für Continuous Integration ist unerlässlich, um die Entwicklung, das Testen und die Bereitstellung Ihrer Anwendungen zu optimieren, da sie Steuermechanismen, Prüfpunkte und eine höhere Geschwindigkeit ermöglicht.

Bewährte Verfahren für Continuous Integration

Der Prozess der kontinuierlichen Integration ist eine wichtige Komponente von DevOps, die Ihnen dabei hilft, die Aktivitäten Ihrer Entwicklungs- und Betriebsteams in einem gemeinsam genutzten Repository für das Codieren, Testen, Bereitstellen und Unterstützen von Software zu vereinen. Die nachfolgend genannten bewährten Verfahren für Continuous Integration können helfen, dass Sie dabei erfolgreich sind:

• Ein einziges Quellcode-Repository verwalten und pflegen:  Verwenden Sie die Quellcodeverwaltung, um alle Dateien für die Erstellung eines Produkts zu überwachen und zu steuern. Diese konsolidierte Codebasis erleichtert die Weitergabe und verbessert die Sichtbarkeit.
  
  
• Build automatisieren:  Dies bezieht das Kompilieren, das Verknüpfen und andere Prozesse ein, durch die die Build-Artefakte erzeugt werden. Selbsttests sollten ebenfalls automatisiert werden.
  
  
• Tägliche Festschreibungen (Commits) in der Codebasis:  Verpflichten Sie die Entwickler dazu, ihre Änderungen mindestens einmal pro Tag im Hauptdatenstrom der Entwicklung festzuschreiben. Jeder Entwickler muss überprüfen, ob seine Arbeitskopie mit dem Hauptstrom der Entwicklungsdaten konsistent ist.
  
  
• Test in einem Klon der Produktionsumgebung durchführen:  Gestalten Sie die Testumgebung so, dass sie ihrer finalen Produktionsumgebung möglichst ähnlich ist.
  
  
• Bereitstellung automatisieren:  Implementieren Sie mehrere Umgebungen (Entwicklung, Integration, Produktion) zum Ausführen von Builds und Tests.