Zentrale Komponenten der DevOps-Pipeline

Die heutige Softwareentwicklung ist darauf ausgerichtet, Anwendungen schnell zu entwickeln, zu testen und bereitzustellen. Fortschrittliche Automatisierungstools spielen dabei eine entscheidende Rolle. DevOps vereint diese methodischen und technischen Elemente und wendet sie auf reale Softwareprojekte an.

In diesem Blogbeitrag geht es um DevOps-Konzepte und die zentralen Komponenten der DevOps-Pipeline. Außerdem erhalten Sie praktische Empfehlungen, wie Sie die DevOps-Methodik in den Softwareentwicklungslebenszyklus (SDLC) integrieren.

Was ist eine DevOps-Pipeline?

Eine DevOps-Pipeline hilft Teams mithilfe einer Kombination aus Tools und Methoden, Software schnell und effizient zu erstellen, zu testen und bereitzustellen. Sie erleichtert auch die Wartung und Aktualisierung von Software. Darüber hinaus vereinfacht eine DevOps-Pipeline die kontinuierliche Integration von Codeänderungen in ein Upstream-Repository, automatisiert Tests und Builds und ermöglicht es, Codekonflikte effizient zu lösen sowie Bugs und Sicherheitslücken zu erkennen. DevOps-Praktiken verkürzen so die Markteinführungszeit (TTM) und ermöglichen agile Softwareentwicklungsprozesse.

Kontinuierliche Integration (CI)

Bei der kontinuierlichen Integration (CI) wird der Code von Entwicklerinnen und Entwicklern regelmäßig in einem gemeinsamen Code-Repository zusammengeführt. Anschließend werden automatische Unit-Tests, Builds und Codeüberprüfungen auf diesen Code angewendet. CI soll vor allem einen effizienten Prozess zur Codeüberprüfung ermöglichen und Codekonflikte zum Zeitpunkt der Veröffentlichung vermeiden.

Dazu wird der in das gemeinsame Repository übertragene Code automatisch kompiliert und als Artefakt erstellt und getestet. Bei diesem als Build bezeichneten Prozess werden die Entwicklerinnen und Entwickler bei Fehlern über fehlgeschlagene Tests und Assertions informiert, die das Problem verursachen, damit sie den Code korrigieren können. Die CI-Pipeline wird üblicherweise mit standardisierten Verfahren zur Codepflege kombiniert, etwa mit Pull Requests.

CI verhindert Probleme wie „Integrationshölle“ und „Merge Day“, wenn verschiedene Branches der Codebasis zusammengeführt werden müssen.

Kontinuierliche Bereitstellung (CD)

Bei der kontinuierlichen Bereitstellung (CD) wird Code in auslieferbare Einheiten verpackt, die sich in der Produktionsumgebung bereitstellen lassen. CD ist nicht mit „Continuous Deployment“ zu verwechseln – der automatischen Bereitstellung von Codeänderungen in der Produktionsumgebung.

Die CD-Umgebung umfasst eine Sandbox, die der Produktionsumgebung ähnelt und in der inkrementelle Codeupdates getestet und freigegeben werden. Nach der Codeüberprüfung und den Tests können Entwicklerinnen und Entwickler Änderungen in die Produktionsumgebung übertragen. Die Veröffentlichung kleiner Codeupdates in der Produktionsumgebung erleichtert die Fehlerbehebung und hilft, Softwareengpässe und Merge-Konflikte zu vermeiden. Dank vorheriger Tests in der Sandbox sind Anwendungen, die über CD in der Produktionsumgebung bereitgestellt werden, in der Regel stabiler und weisen weniger Bugs auf.

Kontinuierliches Deployment (CD)

Kontinuierliches Deployment (CD) bezeichnet die automatisierte Auslieferung von Codeupdates an Nutzerinnen und Nutzer, ohne dass manuelle Prüfungen oder Auslöser erforderlich sind. Wie bei CD werden automatisierte Builds und Tests auf den Code angewendet. Änderungen werden jedoch sofort in die Produktionsumgebung übertragen. CD ermöglicht daher die schnellste Produktfreigabe. Allerdings ist diese Methode auch mit Einschränkungen verbunden. So kann CD beispielsweise Bugs und Sicherheitslücken in die Produktionsumgebung übertragen, die bei automatisierten Prüfungen übersehen wurden. CD sollte daher sorgfältig und nur bei geringfügigen Codeänderungen eingesetzt werden. Außerdem sollte sie mit effizienten Rolling-Update-Verfahren kombiniert werden, etwa mit Blue-Green-Deployments und Canary-Releases.

Eine DevOps-Pipeline aufbauen

Eine effiziente DevOps-Pipeline sollte die folgenden grundlegenden Komponenten umfassen:

• CI/CD-Framework

• Quellcodeverwaltung

• Build-Automatisierungstools

• Framework für Code-Tests

Zusätzlich können Pipeline-Tools für Container-Sicherheit und IaC-Sicherheit zum Einsatz kommen. Viele Open-Source-DevOps-Tools helfen dabei, eine effiziente DevOps-Pipeline aufzubauen.

CI/CD-Framework

CI/CD-Frameworks wie Jenkins oder Travis CI unterstützen bei der Umsetzung der CI/CD-Komponente einer DevOps-Pipeline. Solche Frameworks umfassen in der Regel einen Server, der Software anhand eingehender Code-Commits automatisch erstellen, testen und bereitstellen kann. Ihr CI/CD-Tool sollte daher mit dem Quellcode-Repository verbunden sein.

Quellcodeverwaltung

Tools zur Quellcodeverwaltung (oder Versionskontrolle) ermöglichen es, Codeänderungen nachzuverfolgen und zu verwalten. Sie stellen einen fortlaufenden Entwicklungsverlauf bereit, einschließlich einzelner Commits von Entwicklerinnen und Entwicklern sowie Pull Requests. Außerdem helfen sie dabei, Codeänderungen in Remote-Repositories zu übertragen und Konflikte zwischen verschiedenen Beiträgen zu lösen. Unter den Tools zur Quellcodeverwaltung bietet Git das ausgereifteste Ökosystem und ist am weitesten verbreitet.

Build-Automatisierungstools

Build-Automatisierungstools verpacken den Anwendungscode in ein bereitstellbares Objekt. Welche Funktionen diese Tools bieten, hängt davon ab, welche Art von Programmiersprache verwendet wird: eine kompilierte oder eine interpretierte Sprache.

Tools für kompilierte Sprachen wie C++ oder Java kompilieren nicht nur Code, sondern erstellen auch eine native Build-Umgebung, um Quellcode zu kompilieren, Bibliotheken und Wrapper zu erstellen und ausführbare Dateien in verschiedenen Kombinationen zu generieren. Build-Tools für interpretierte Sprachen wie Grunt, Webpack, Rollup und Babel für JavaScript können JavaScript-Dateien zusammenführen sowie verschleiern und minimieren.

Framework für Code-Tests

Frameworks für Code-Tests helfen Entwicklerinnen und Entwicklern, Anwendungsfehler während der Entwicklung zu erkennen. Diese Tools umfassen in der Regel Funktionen für Unit-Tests, die sich in den Anwendungscode integrieren und zur Laufzeit ausführen lassen. Außerdem können Frameworks für Code-Tests in vorhandene CI/CD-Tools eingebunden werden, um den Prozess zu automatisieren. Für die verschiedenen Programmiersprachen stehen zahlreiche Test-Frameworks zur Verfügung, etwa Pytest für Python und JUnit für Java.

Durch einen automatisierten Snyk Code-Test in Ihrer CI/CD-Pipeline lassen sich auch Codequalitäts- und Sicherheitslücken-Scans in den Build-Prozess integrieren.

Beispiel für eine Azure DevOps-Pipeline

Die meisten Cloud-Anbieter stellen verschiedene Tools bereit, mit denen sich in der Cloud eine DevOps-Pipeline für den Produktionseinsatz aufbauen lässt. Um zu veranschaulichen, wie eine Cloud-DevOps-Pipeline in der Praxis aussieht, betrachten wir die Microsoft Azure DevOps-Pipeline. Sie besteht aus verschiedenen Komponenten, darunter:

• Azure Pipelines

• Azure Test Plans

• Azure Repos

• Azure DevOps Server

Diese Tools bieten alle oben beschriebenen DevOps-Bausteine.

So könnte der Ablauf mit der Microsoft Azure DevOps-Pipeline aussehen:

1. Der Anwendungscode wird aktualisiert.

2. Codeänderungen werden in das Code-Repository in Azure Repos übertragen.

3. Ein CI-Ereignis löst den Anwendungsbuild und Unit-Tests mit Azure Test Plans aus.

4. Azure Pipelines erstellt eine automatisierte Bereitstellung der Anwendungsartefakte.

5. Die Artefakte werden in Azure App Service bereitgestellt.

6. Nach der Bereitstellung der Anwendung können DevOps-Spezialistinnen und -Spezialisten den Zustand, die Performance und weitere Anwendungsmetriken überwachen.

Sicherheit in die DevOps-Pipeline integrieren

Die Anwendungssicherheit mit traditionellen Ansätzen, die in vielen Unternehmen noch immer zum Einsatz kommen, ist nicht mit DevOps vereinbar. Diese Ansätze weisen in der Regel folgende Einschränkungen auf:

• Sicherheit wird normalerweise erst nach der Produktion berücksichtigt, statt von Anfang an integriert zu sein.

• Die langsamen Feedbackzyklen traditioneller Sicherheitspraktiken sind mit der hohen Geschwindigkeit einer DevOps-Pipeline nicht vereinbar.

• Traditionelle Sicherheitsmethoden berücksichtigen nicht die dynamischen Umgebungen, in denen moderne Anwendungen betrieben werden, etwa Cloud-Dienste, Container und Containerverwaltungssysteme wie Kubernetes.

Sicherheitsteams, die dem traditionellen Ansatz folgen, sind nicht Teil der DevOps-Gruppen. Sie berichten in der Regel an andere Teamleitungen und arbeiten isoliert. Dadurch werden unsichere Anwendungen ausgeliefert: Die Fachleute sind nicht in den Informationsfluss eingebunden und haben keinen Zugriff auf die Informationen, die sie benötigen.

Außerdem verzögern Sicherheitsteams in solchen Fällen die Auslieferung, wenn sie Audits durchführen – und untergraben damit das ursprüngliche Geschäftsziel. Erschwerend kommt hinzu, dass Sicherheitsteams oft stark unterbesetzt sind. Dazu trägt der gravierende Fachkräftemangel in der Cybersicherheitsbranche bei.

Wenn Sicherheitsteams Sicherheitslücken und andere Risiken aufdecken, können sie die Probleme nicht selbst beheben. Die Suche nach einer Lösung wird an das Entwicklungsteam weitergegeben. Bis die Probleme priorisiert und behoben sind, bleibt das Risiko bestehen. Dadurch entsteht ein weiterer Engpass bei der Behebung von Sicherheitsproblemen.

Diese Einschränkungen traditioneller Sicherheitsansätze erschweren die Integration von Sicherheit in eine moderne DevOps-Umgebung, die auf Automatisierung und CI/CD-Instrumentierung ausgelegt ist. Sicherheit bleibt ein Fremdkörper im Softwareentwicklungsprozess und wird erst nach der Erstellung des Softwareprodukts als Korrekturmaßnahme eingesetzt. Zum Glück gibt es eine Lösung für dieses Problem.

Developer-First-Security und DevSecOps

In der digital transformierten Welt von Cloud und DevOps ist ein neuer Sicherheitsansatz gefragt. Dieser neue Ansatz, auch als DevSecOps bezeichnet, muss auf den neuen Technologien und Methoden aufbauen und Sicherheit von Grund auf integrieren. Er muss eigenständige Teams stärken und das Geschäft beschleunigen, statt es auszubremsen. Mit anderen Worten: Der Ansatz muss Developer-First sein.

Was ist DevSecOps?

DevSecOps integriert Sicherheitspraktiken in ein DevOps-Modell für die Softwarebereitstellung. Dieser Ansatz ist eine natürliche Weiterentwicklung von DevOps und ergänzt das Konzept der „gemeinsamen Verantwortung“ um eine Sicherheitsdimension. DevSecOps betrachtet Sicherheit als integriertes Softwaremerkmal, das denselben Überprüfungs- und Compliance-Prozessen unterliegt wie andere Komponenten der DevOps-Pipeline.

Zu den wichtigsten Vorteilen von DevSecOps gehören:

• Sicherheitsaktivitäten und -tools werden frühzeitig in den Softwareentwicklungslebenszyklus integriert.

• Die Softwarebereitstellung wird beschleunigt, da Bugs und Sicherheitslücken früh erkannt und vor der Bereitstellung behoben werden. So können sich Entwicklerinnen und Entwickler darauf konzentrieren, nützliche Funktionen auszuliefern.

• Tools zur Sicherheitsautomatisierung ermöglichen es Entwicklerinnen und Entwicklern ohne Sicherheitsexpertise, stabile und sichere Software zu erstellen.

Es gibt einige erfolgreiche Beispiele dafür, wie DevSecOps umgesetzt und Sicherheit in DevOps-Pipelines integriert werden kann. Bei Coveo können Mitglieder des DevOps-Teams Sicherheitslücken deutlich autonomer und effizienter verwalten. Die Security Champions der einzelnen Teams können Sicherheitslücken überwachen und selbst entscheiden, wie und innerhalb welchen Zeitraums sie behoben werden. Die DevOps-Teams bei Coveo werden beaufsichtigt, erhalten insgesamt aber die Verantwortung und Befugnis, ihre Sicherheitsmaßnahmen zu priorisieren. Die Unterstützung von Snyk für diesen „Trust-but-Verify“-Ansatz hat die Einführung im gesamten Unternehmen erheblich erleichtert.

„Die Deployment-Pipeline wurde zunächst von einem kleinen Team entwickelt und später allen Entwicklerinnen und Entwicklern zur Verfügung gestellt“, erklärte Beaumont. „Wir mussten die Entwicklungsteams nicht wirklich davon überzeugen, die neue Pipeline einzusetzen, denn sie bot sowohl in puncto Sicherheit als auch Benutzerfreundlichkeit zahlreiche Vorteile. Der Übergang vollzog sich ganz natürlich.“

Jean-Philippe Lachance, Sicherheitsanalyst, Coveo

Fazit

In diesem Artikel haben wir die zentralen Komponenten der DevOps-Pipeline und ihre Integration in den Softwareentwicklungsprozess kennengelernt. Eine DevOps-Reise beginnt nicht allein mit der Auswahl der richtigen Tools. Entscheidend sind auch bewährte organisatorische DevOps-Praktiken und eine entsprechende Kultur, die auf gemeinsamer Verantwortung, Automatisierung und Zusammenarbeit zwischen Entwicklerinnen und Entwicklern, Administratorinnen und Administratoren sowie Operations-Spezialistinnen und -Spezialisten basiert.

Doch denken Sie daran: Bei der DevOps-Pipeline geht es nicht nur um schnelle Entwicklungs- und Release-Zyklen, sondern auch um die Sicherheit Ihrer Anwendungen. Dazu müssen Sie Sicherheit in Ihre DevOps-Pipeline integrieren und verschiedene Teams auf das Ziel ausrichten, Anwendungen von Anfang an sicher zu entwickeln. Deshalb gewinnen die in diesem Artikel behandelten aufkommenden DevSecOps-Praktiken in der modernen DevOps-Bewegung zunehmend an Bedeutung.

DevOps-FAQ