Erfolgreich mit AWS in die CI/CD-Welt starten

Einleitung

Die Umsetzung von Continuous Integration und Continuous Delivery (CI/CD) in einer Cloud-Umgebung ist zweifellos ein anspruchsvoller, aber unverzichtbarer Schritt auf dem Weg zu effizienten und zuverlässigen Prozessen in der Softwareentwicklung. Dieser Beitrag stellt bewährte Methoden vor, wie der Einstieg in die CI/CD-Welt von Amazon Web Services (AWS) strategisch geplant und erfolgreich umgesetzt werden kann. Ein tiefgreifendes Verständnis der Grundstruktur von CI/CD, sowie Software-Testings und dem Zusammenspiel verschiedener Cloud-Services ist entscheidend, um eine erfolgreiche CI/CD-Implementierung zu gestalten, die eine solide Grundlage für sichere und effiziente Softwareentwicklung schafft. 

Begriffserklärung CI/CD 

CI/CD repräsentiert einen Arbeitsablauf oder eine Pipeline für die Softwarebereitstellung, bei der aktualisierter Code eingereicht, über verschiedene Phasen getestet und schließlich als produktionsbereiter Code veröffentlicht wird (siehe Abbildung 1). Jede Stufe der CI/CD-Pipeline fungiert als eine logische Einheit im Bereitstellungsprozess, welche einen spezifischen Aspekt des Codes überprüft. Beim Durchlaufen der Pipeline wird von einer kontinuierlich zunehmenden Codequalität ausgegangen, da immer mehr Aspekte des Codes in den bereits durchlaufenen Stufen überprüft wurden. Diese Vorgehensweise ermöglicht schlanke Entwicklungsprozesse durch frühzeitige Erkennung von potenziellen Problemen. Dies ermöglicht eine gesteigerte Produktivität, ohne die Softwarequalität zu vernachlässigen.

Der von AWS bereitgestellte Service AWS CodePipeline bietet die Flexibilität, einzelne Phasen des CI/CD-Prozesses modular zu einer vollumfänglichen Pipeline zusammenzustellen. Durch die enge Integration von CodePipeline mit verschiedenen AWS-Services wie AWS CodeBuild, AWS CodeDeploy, AWS Lambda und Amazon Elastic Container Service (ECS) können Entwicklerteams maßgeschneiderte CI/CD-Pipelines entwerfen und automatisierte Workflows für die reibungslose Bereitstellung von Anwendungen gestalten.

CI/CD-Stufen im Detail

Die im Einzelnen erläuterten Phasen des CI/CD-Prozesses, in diesem Abschnitt, dienen der Veranschaulichung und können flexibel an die Anforderungen Ihres Geschäfts angepasst werden. Je nach Projektkomplexität können einige Stadien für unterschiedliche Umgebungen oder verschiedene Testarten, wie Anwendungssicherheits- und Performance-Tests, wiederholt werden. Ein iterativer Ansatz bei der Implementierung neuer CI/CD-Pipelines ist von entscheidender Bedeutung, um aus den gesammelten Erfahrungen die Pipeline progressiv weiterzuentwickeln. Selbst Organisationen mit hochentwickelten CI/CD-Umgebungen müssen fortlaufend daran arbeiten, ihre Pipelines zu erweitern. Diese Vorgehensweise entspricht den Prinzipien der DevOps-Kultur, die auf einer kontinuier-lichen und iterativen Weiterentwicklung beruht. Wir schlagen unseren Kunden vor mit einem Minimum Viable Product (MVP) zu starten, anstatt beim ersten Versuch eine vollständig ausgereifte Pipeline für verschiedene Umgebungen, unterschiedliche Testphasen und umfassende Automatisierungen in allen Stufen etablieren zu wollen. 

Einrichtung der Quelle

In jeder CI/CD-Pipeline ist die Integration mit einem zentralen Repository vorgesehen. Hierbei bieten sich Plattformen wie GitHub, Bitbucket oder AWS-native Services wie AWS CodeCommit an. Für eine reibungslose Zusammenarbeit ist von entscheidender Bedeutung, dass Entwickler regelmäßig ihre Codeänderungen in das Repository einpflegen und im Master-Branch zusammenzuführen. Um einen Code-Standard zu gewährleisten, empfiehlt es sich, Precommit-Hooks sowie in die IDE (Integrated Development Environment) integrierte Tools zur Codeanalyse in den Arbeitsprozessen zu integrieren. 

Einrichtung von Building Tool

Für den CI-Prozess ist Automatisierung von Builds eine essenzielle und grundlegende Praktik. Die Auswahl eines geeigneten Build-Tools hängt von der im Projekt verwendeten Programmiersprache und der Erfahrung der Entwickler ab. Wir raten Ihnen, die erstellten Build-Artefakte in einem S3-Bucket zu speichern und dabei Versionsnummern hinzuzufügen, um die Rückverfolgbarkeit zu vereinfachen. 

Build-Phase

Die Build-Phase wird automatisch durch Modifikationen am Quellcode aus der zentralen Repository initiiert und kompiliert den aktualisierten Code, welcher anschließend für Tests bereitsteht. Generell sollte das Testen so früh wie möglich beginnen. Die Ausführbarkeit bestimmter Tests wird von der zugrundeliegenden Umgebung bestimmt. Zum Beispiel erfordern Performance-Tests eine Umgebung, die der Produktionsumgebung ähnelt, während Unit-Tests in einer isolierten Testumgebung durchgeführt werden können. Die Testpyramide von Mike Cohn ist ein weitverbreitetes Konzept aus dem Buch "Succeeding with Agile" und stellt einen Vergleich verschiedener Softwaretests hinsichtlich ihrer Kosten und Ausführungsgeschwindigkeit dar (siehe Abbildung 2). Unit-Tests bilden die Basis der Pyramide. Sie sind die schnellsten und kostengünstigsten Tests und sollten daher den Großteil der Teststrategie ausmachen, idealerweise etwa 70 Prozent. Da Bugs in diesem Stadium schnell und kostengünstig behoben werden können, sollten Unit-Tests eine nahezu vollständige Codeabdeckung haben. 

Staging-Phase

Die Staging-Umgebung ist eine spezielle Testumgebung, die darauf abzielt, die zukünftige Produktionsumgebung möglichst genau zu replizieren. In dieser Umgebung wird eine Vielzahl von Tests durchgeführt, darunter Integrationstests, diverse Sicherheitsprüfungen, Performance-Tests und Compliance-Tests. Besonderes Augenmerk liegt auf der unteren Hälfte der Testpyramide, um eine agile Entwicklung zu ermöglichen. Durch diese Tests wird sichergestellt, dass die Anwendung in einem realitäts-nahen Szenario reibungslos funktioniert und eventuelle Probleme frühzeitig erkannt werden, noch bevor die Software in die produktive Umgebung überführt wird. 

Produktion

Nach erfolgreicher Staging-Phase erfolgt die Bereitstellung des Codes in die Produktionsumgebung. Hierbei bietet sich die Anwendung verschiedener Strategien an, darunter der abschließende Canary-Test. Dabei wird der neue Code zunächst auf einem begrenzten Teil der Server oder in einer spezifischen AWS-Region ausgerollt und überwacht, bevor die Änderung auf die gesamte Produktionsumgebung ausgerollt wird. 

Erweiterte Schritte in AWS CodePipeline: Lambda-Funktionen und manuelle Freigaben 

Der Einsatz von Lambdas in AWS CodePipeline ermöglicht die Implementierung von individuellen und automatisierten Aufgaben im Rahmen eines CI/CD-Prozesses. So können etwa bedarfsabhängig Resources temporär erstellt oder gelöscht, aber auch Drittanbieterprodukte in die Pipeline integriert werden. 

Manuelle Freigaben bieten die Möglichkeit, die Pipeline-Verarbeitung an einem bestimmten Punkt anzuhalten und menschliche Überprüfungen in den CI/CD-Prozess zu integrieren. Sobald dieser Schritt erreicht ist, pausiert die Pipeline und wartet auf die Genehmigung von vordefinierten Benutzern. Diese Funktion gewährleistet eine zusätzliche Sicherheitsebene und ermöglicht die sorgfältige Überprüfung kritischer Änderungen der Anwendung und IT-Infrastruktur. 

Teamzusammenstellung

Bei der Einführung von CI/CD in Ihrer Organisation empfiehlt es sich drei Entwicklerteams für die Implementierung einer CI/CD-Umgebung zusammenzustellen: ein Anwendungsteam, ein Infrastrukturteam und ein Tools-Team (siehe Abbildung 3). Diese Organisationsstruktur repräsentiert bewährte Praktiken, die in schnell wachsenden Start-ups und großen Unternehmensorganisationen und bei Amazon selbst entwickelt und angewendet wurden.

Das Anwendungsteam gestaltet die Anwendung und ist zuständig für Backlog, Storys und Testing. Sie entwickeln Funktionen entsprechend einem definierten Anwendungsziel. Die Teammitglieder sollten möglichst wenig Zeit für Anwendungsaufgaben, die nicht zum Kern gehören, aufwenden. 

Das Infrastrukturteam ist für den Code zur Erstellung und Konfiguration der für die Anwendung benötigten Infrastruktur zuständig. Hierzu empfiehlt sich die Verwendung von Infrastructure as Code (IaC), da es die automatisierte Erstellung und Verwaltung der Infrastruktur ermöglicht. Beispiele für IaC-Technologien sind AWS CloudFormation, HashiCorp Terraform oder Ansible, die es erlauben, Infrastrukturressourcen und Konfigurationen programmatisch zu definieren und zu verwalten. Das Infrastrukturteam arbeitet eng mit dem Anwendungsteam zusammen. Bei kleineren Anwendungen kann bereits ein Team von ein oder zwei Personen im Infrastrukturbereich ausreichend sein. 

Das Tools-Team konzipiert und betreut die CI/CD-Pipeline. Dessen Mitglieder tragen die Verantwortung für die Infrastruktur und die Werkzeuge, aus denen sich die Pipeline zusammensetzt und von den Anwendungs- und Infrastrukturteams genutzt werden. Die kontinuierliche Weiterentwicklung des Tools-Teams ist von besonderer Bedeutung, um den fortschreitenden Anwendungs- und Infrastrukturteams stets einen Schritt voraus zu sein. Ihre konkreten Aufgaben umfassen das Einrichten von Repositories für die Quellcodeverwaltung, die Gestaltung von Workflow-Engines, die Konfiguration von Build-Umgebungen, die Integration von Testframeworks sowie die Verwaltung von Artefakt-Repositories. 

Fazit

Die Integration von CI/CD in der Cloud-Umgebung ist ein wesentlicher Schritt für effiziente und automatisierte Prozess-Abläufe in der Softwareentwicklung. Der aktuelle Wandel von DevOps zu DevSecOps reflektiert die zunehmende Relevanz der Einbindung von Sicherheitsaspekten über den gesamten Softwareentwicklungszyklus zur Gewährleistung von Unternehmens-Compliance.  

Um CI/CD erfolgreich in Ihrer Organisation zu etablieren, ist es entscheidend, mit einem Minimal Viable Product (MVP) zu beginnen und die Entwicklung iterativ gemäß den Geschäftsanforderungen und der gesammelten Erfahrung voranzutreiben. Hierzu empfiehlt es sich ein dediziertes Team aufzustellen, sodass sich die Entwickler Ihrer Anwendungssoftware auf ihre Kernaufgaben konzentrieren können. Profitieren Sie dabei von unserer Expertise als AWS-Partner auf dem Weg zur Festigung von DevOps-Praktiken in Ihrer Organisation.