Was ist CI/CD? CI/CD-Pipelines und Tools erklärt

Innerhalb einer Generation hat sich CI/CD von einem Nischenthema zu einem weitverbreiteten Ansatz für die Softwareentwicklung und -bereitstellung entwickelt, der in der Branche mittlerweile als selbstverständlich gilt. Obwohl viele den Begriff ganz selbstverständlich verwenden, werden die genauen Bedeutungen von CI und CD häufig falsch verwendet und missverstanden.

CI/CD erklärt

Was sind die wichtigsten Bestandteile einer CI/CD-Pipeline?

Was ist Continuous Integration (CI)?

Continuous Integration (CI) wird allgemein als Entwicklungspraxis verstanden, bei der Code aus der Entwicklung regelmäßig in einen einzigen Branch integriert wird. Dieser einzelne Branch wird üblicherweise „Trunk“ genannt. Teams können zwar aus bestimmten Gründen eigene Branches erstellen (z. B. für einen Hotfix auf einem Live-System), doch gelten solche Fälle als Ausnahmen von der Regel.

 Um laufende Arbeiten zu verwalten, werden „Feature-Flags“ eingesetzt. Sie stellen sicher, dass der Code erst aktiviert wird, wenn er fertig ist. Dieser Ansatz mit einem einzelnen Branch unterscheidet sich von anderen Entwicklungsformen wie GitFlow, bei denen es mehrere langfristig bestehende Branches gibt, die parallele Entwicklungsstränge ermöglichen.

Die Bedeutung von CI im CI/CD-Framework 

Mit CI vermeiden Sie das traditionelle Problem des „Merge Day“, an dem diese Entwicklungsstränge sorgfältig zusammengeführt werden müssen. Dieser Abgleich kann kompliziert und fehleranfällig sein und das Vertrauen in die Veröffentlichung von Codeänderungen insgesamt mindern. CI fördert auch weitere bewährte Praktiken, etwa regelmäßige Tests Ihrer Unit- oder Integrationstests, wenn Sie eine automatisierte CI-Pipeline nutzen. Aus technischer Sicht erfordert CI, dass Entwickler ihre laufenden Arbeiten häufig in einen einzigen Branch einchecken (d. h. sie erstellen für ihre Features überhaupt keine eigenen Branches). In der Praxis wird diese Vorgabe jedoch nicht immer eingehalten.

Was ist Continuous Delivery (CD)?

Continuous Integration sorgt dafür, dass Änderungen in der Entwicklung regelmäßig in die Haupt-Codebasis integriert werden. Continuous Delivery bündelt den Code zu einer auslieferbaren Einheit, die anschließend von den Entwicklern selbst (in einem reinen DevOps-Modell) oder bei Bedarf von einem separaten Betriebsteam bereitgestellt werden kann. Häufig wird dies mit „Continuous Deployment“ verwechselt oder gleichgesetzt. Der Begriff bezeichnet einen Prozess, bei dem Änderungen automatisch in der Produktionsumgebung bereitgestellt werden. Auch hier ist die zweite Verwendung in der Praxis häufiger als die technische Definition.

Was ist Continuous Deployment?

Continuous Deployment ermöglicht es Unternehmen, ihre Anwendungen automatisch zu veröffentlichen, ohne dass ein manueller Eingriff erforderlich ist. Bei diesem Ansatz legen DevOps-Teams im Voraus Veröffentlichungskriterien fest. Sobald diese Kriterien erfüllt und überprüft sind, wird der Code direkt in die Produktionsumgebung übertragen. So können Unternehmen schneller auf Veränderungen reagieren und neue Funktionen früher für Nutzer bereitstellen.

Continuous Integration (CI) lässt sich auch ohne Continuous Delivery (CD) oder Deployment praktizieren. CD setzt jedoch voraus, dass CI bereits implementiert ist. Eine bedarfsgesteuerte Bereitstellung in der Produktionsumgebung wäre ohne CI-Grundlagen wie die Integration von Code in ein gemeinsames Repository, automatisierte Tests und Builds sowie kleine, häufige Arbeitsschritte im Tagesverlauf nahezu unmöglich.

Was ist eine CI/CD-Pipeline?

Automatisierung eignet sich ideal für CI- und CD-Praktiken, da dabei regelmäßig dieselben Schritte ausgeführt werden müssen. Die Automatisierung von CI- und CD-Prozessen wird üblicherweise als „Pipeline“ bezeichnet – in Anlehnung an automatisierte Produktionsstraßen in Fabriken. Da Automatisierung ein zentrales DevOps-Prinzip ist (das „A“ im CALMS-Modell für DevOps), gelten CI/CD-Pipelines häufig als wesentlicher Bestandteil der DevOps-Praxis. Ein einzelnes Team kann die Pipeline bis zur Produktionsumgebung erstellen und verwalten (ein stärker am ursprünglichen DevOps-Modell orientierter Ansatz). Alternativ kann die CI/CD-Pipeline stabile, gründlich getestete Build-Artefakte an ein separates Betriebsteam zur Bereitstellung übergeben.

Vorteile der CI/CD-Integration

Eine CI/CD-Pipeline erleichtert auch die Einführung weiterer Änderungen, die die Zuverlässigkeit verbessern können. So lassen sich beispielsweise Unit- oder Integrationstests problemlos früher in den Build- und Bereitstellungszyklus integrieren. Dies wird als „Shifting Left“ bezeichnet und kann erhebliche Kosteneinsparungen bewirken, da Probleme früher im Bereitstellungsprozess entdeckt werden.

Pipelines fördern außerdem eine Umgebung, in der Änderungen „in kleinen Schritten und häufig“ veröffentlicht werden können. Das senkt ebenfalls das Risiko, da jede dieser kleineren Änderungen für das Gesamtsystem weniger riskant ist. Beim traditionelleren „Big-Bang“-Ansatz hingegen werden viele Änderungen zu einer einzigen, umfangreichen und unregelmäßigen Veröffentlichung zusammengefasst.

Schließlich verringert der geringere Bedarf an manuellen Eingriffen das Risiko zusätzlich, da Maschinen zuverlässiger sind als Menschen. Es ist unwahrscheinlich, dass eine automatisierte Pipeline im Rahmen eines Builds den falschen Befehl ausführt oder während eines Veröffentlichungszyklus einen QA-Test vergisst.

Die zunehmende Popularität von GitOps baut auf diesem Pipeline-Code auf und verlangt, dass die Pipeline vollständig in der Versionsverwaltung abgebildet wird. Darüber hinaus verwalten automatisierte Steuerungsagenten den Bereitstellungsstatus und stellen sicher, dass dieser dem Quellcode entspricht.

CI/CD-Pipelines und Sicherheit

Beim Management der Softwaresicherheit hat die zunehmende Verbreitung von CI/CD-Pipelines neue Chancen, aber auch neue Bedrohungen mit sich gebracht. Positiv ist, dass CI/CD-Pipelines den uneingeschränkten Zugriff auf Build- und Bereitstellungsprozesse einschränken. Außerdem lässt sich den betreffenden Nutzern – sowohl „echten“ Nutzern als auch Services – einfacher ein fein abgestufter Zugriff auf genau die benötigten Ressourcen gewähren, statt ihnen vollständige Administratorrechte einzuräumen. Pipelines verbessern zudem die Nachvollziehbarkeit von Build- und Bereitstellungsprozessen erheblich: Für jeden Schritt lässt sich relativ einfach protokollieren, welche Aktion ausgeführt wurde, welches Ergebnis sie hatte und wodurch beziehungsweise von wem sie ausgelöst wurde.

Wie bereits erwähnt, bringt CI/CD natürlich auch eine Zunahme der Bedrohungen mit sich. Seit dem Jahr 2000 haben verschiedene Faktoren zu einer Vervielfachung der Code-Menge sowie der Quellen und Softwareplattformen geführt. Da Entwicklung und Bereitstellung immer schneller werden und Pipelines zunehmend zuverlässig funktionieren, wird Software heute schneller als je zuvor bereitgestellt.

Die zunehmende Verbreitung von Open-Source-Softwarebibliotheken, Plattformen und Tools hat Entwicklern zudem eine deutlich größere Auswahl an Software eröffnet. Schließlich ermöglichen Containerisierung als flexible Technologie für Paketierung und Bereitstellung sowie die Interoperabilität von Softwarekomponenten über REST-Schnittstellen und gRPC, diese Komponenten einfacher und schneller als je zuvor gemeinsam zu erstellen und bereitzustellen.

Zusammengenommen haben diese Faktoren eine Flut neuer Software ausgelöst, die zentralisierte Abteilungen verwalten müssen. Sicherheits-, Betriebs- und Architekturteams mussten sich alle an dieses neue und sich ständig verändernde Umfeld anpassen.

Dieser Druck hat zur Entstehung von DevSecOps geführt – einer Erweiterung des DevOps-Modells, das die gemeinsame Verantwortung für Entwicklung, Bereitstellung und Wartung vorsieht und Sicherheitsbelange eng einbezieht.

Play Video: CI/CD workflows

CI/CD-Pipeline-Tools

CI/CD-Pipelines begannen als Kombinationen aus einfachen Shell-Skripten und Nachfolgern von Make-Dateien wie Ant und Maven. Mit der Zeit kamen immer häufiger umfassendere Anwendungen zum Einsatz, die diese Funktion übernehmen. Einige davon waren zunächst einfache serverseitige Anwendungen, entwickelten sich später jedoch zu erfolgreichen kommerziellen Produkten. Zu den größten Anbietern in diesem Bereich zählen Jenkins und TeamCity. Ursprünglich speicherten diese Tools ihre Pipeline-Konfiguration serverseitig zustandsbehaftet über die grafische Benutzeroberfläche der Anwendung. In jüngerer Zeit haben sich jedoch deklarative „Pipelines as Code“ etabliert, die aus Remote-Quellcode-Repositories abgerufen werden.

Snyk kann Sie beispielsweise mit statischen Anwendungssicherheitstests dabei unterstützen, kontinuierlich bekannte Schwachstellen in Ihren Abhängigkeiten zu vermeiden. Snyk bietet Sicherheitsintegrationen für TeamCity, Jenkins und viele weitere CI/CD-Tools und -Systeme. In unserem GitHub-Repository finden Sie Beispiele für die Konfiguration von Integrationen mit Snyk.

Play Video: Why and when use Snyk in CI/CD?

Auch die großen Anbieter von Versionsverwaltungsdiensten sind in diesen Bereich eingestiegen. GitLab war mit seinem Angebot GitLab CI/CD zuerst dabei; GitHub folgte mit GitHub Actions. Snyk bietet Integrationen sowohl mit GitLab als auch mit GitHub.

Natürlich bieten auch die großen Cloud-Anbieter entsprechende Services an. Azure stellt sein Produkt Pipelines bereit, AWS bietet CodePipeline. Sowohl die Produkte von Azure als auch die von AWS lassen sich mit Snyk integrieren.

CI/CD als neuer Branchenstandard

Seit CI 1991 geprägt wurde, hat sich CI/CD von einer relativ wenig verbreiteten Praxis zum Branchenstandard entwickelt. Zusammen mit dem gegenseitigen Verstärkungseffekt von Open Source, Containerisierung und verteilten Anwendungen hat dies zu einer explosionsartigen Zunahme von Software-Artefakten geführt, die eine scheinbar unendliche Vielfalt an Tools und Technologien umfassen.

Für Verantwortliche von Softwarebereitstellungs-Pipelines ist dadurch jedoch ein Sicherheitsproblem entstanden: Sie müssen all diese neuen Angriffsvektoren unter Kontrolle halten. Manuelle Überprüfungen sind allerdings weder nachhaltig noch effizient oder zuverlässig. Erfahren Sie hier mehr über die verschiedenen Arten von Sicherheitsaudits, die Sie in Ihre Pipeline integrieren können.

Verbessern Sie die Sicherheit für Entwickler während des gesamten Entwicklungsprozesses. Integrieren Sie die Automatisierung Ihrer Pipeline mit dem Schwachstellen-Scanning von Snyk. Hier finden Sie alle Integrationen von Snyk.