In der modernen Softwareentwicklung ist es entscheidend, Software schnell und zuverlässig an Kunden auszuliefern. Doch wie lässt sich sicherstellen, dass jede neue Version stabil, getestet und bereit für die Bereitstellung ist, ohne dass die Entwickler in manuellen Prozessen versinken?

Continuous Integration (CI) sorgt dafür, dass der Code stabil und getestet ist. Doch wie wird dieser Code in ein bereitstellungsfähiges Artefakt umgewandelt, das jederzeit ausgeliefert werden kann? Hier kommt Continuous Delivery (CD) ins Spiel. CD automatisiert den Weg von der Entwicklung bis zur Bereitstellung und ermöglicht es Teams, Releases auf Knopfdruck durchzuführen.

In diesem Artikel, dem zweiten Teil unserer Serie zu CI/CD, zeigen wir, wie Continuous Delivery funktioniert, welche Prozesse es umfasst und wie Teams von dieser Automatisierung profitieren können.

Was bedeutet Continuous Delivery (CD)?

Das Ergebnis der Softwareentwicklung sind sogenannte Software-Artefakte. Diese Artefakte können je nach Art der Software unterschiedlich sein, beispielsweise:

·         Ausführbare Programme (z. B. .exe- oder .apk-Dateien)

·         Bibliotheken (z. B. npm-Pakete oder .dll-Dateien)

·         Container-Images (z. B. Docker-Images)

·         Konfigurationsdateien (z. B. YAML- oder ENV Dateien)

·         Dokumentationen oder Logdateien

Ein Artefakt ist bereit für die Auslieferung, wenn es folgende Kriterien erfüllt:

1. Es wurde erfolgreich gebaut.

2. Es hat alle Tests bestanden.

3. Es ist bereit, in eine Zielumgebung ausgeliefert zu werden.

Continuous Delivery (CD) bedeutet, dass mit jeder Änderung des Main-Branches die dazugehörigen Software-Artefakte automatisch gebaut, getestet und für die Auslieferung vorbereitet werden. Das Ziel besteht darin, die Software jederzeit in einem bereitstellungsfähigen Zustand zu halten.

Build-Pipelines: Automatisierung des Build-Prozesses

Eine Build-Pipeline ist ein automatisierter Workflow, der aus dem Quellcode ein lauffähiges Artefakt erstellt. Jedes Mal, wenn Code in den Main-Branch integriert wird, wird ein Build-Prozess ausgelöst. Dabei werden die folgenden Aspekte berücksichtigt:

1. Build-Tooling:

   1. Tools wie CMake, Maven, uv oder Webpack sorgen dafür, dass der Code kompiliert, verpackt und in ein Artefakt umgewandelt wird.

   2. Komplexe Software-Lieferketten lassen sich durch die Entwicklung kundenspezifischer Build-Tools in den Griff bekommen.

2. Build-Umgebung:

   1. Container-Technologien wie Docker schaffen eine konsistente Build-Umgebung, in der alle notwendigen Build-Tools bereitgestellt werden.

   2. Techniken wie Cross-Compilation ermöglichen es, Artefakte für verschiedene Zielplattformen zu erzeugen.

3. Reproduzierbare Builds:

   1. Ein reproduzierbarer Build garantiert, dass das gleiche Artefakt immer wieder aus demselben Quellcode erstellt werden kann – unabhängig von der Umgebung oder den verwendeten Tools.

   2. Ein wichtiger Faktor ist dabei die reproduzierbare Erstellung der Build-Umgebung selbst.

4. Abnahme-Tests:

   1. Automatisierte Tests stellen sicher, dass das Artefakt stabil und funktionsfähig ist.

   2.  In bestimmten Fällen können auch manuelle Tests erforderlich sein, um spezifische Qualitätsanforderungen sicherzustellen.

      
      

Artefakt-Repositories: Zentrale Ablage für Software-Artefakte

Fertige Artefakte werden in einem Artefakt-Repository gespeichert und verwaltet. Diese Repositories ermöglichen eine zentrale Bereitstellung und Wiederverwendung der Artefakte. Sie lassen sich in zwei Kategorien einteilen:

1. Universelle Repositories

   Diese Repositories unterstützen eine Vielzahl von Artefakt-Typen und sind ideal für Projekte, die mit unterschiedlichen Technologien arbeiten. Sie bieten eine zentrale Plattform für die Verwaltung verschiedenster Artefakte und eine nahtlose Integration mit CI/CD-Tools. Beispiele hierfür sind:

   
   

     JFrog Artifactory: Unterstützt die meisten Paketformate und bietet umfangreiche Integrationsmöglichkeiten mit CI/CD-Tools.

   
   

     Sonatype Nexus: Der Fokus liegt auf Sicherheit und Governance, weshalb es sich ideal für Unternehmen mit hohen Compliance-Anforderungen eignet.

   
   

      GitHub Packages: Es ist direkt in GitHub integriert und ideal für Projekte, die auf GitHub gehostet werden.

   
   

2. Spezialisierte Plattformen

   Diese Repositories sind auf bestimmte Artefakt-Typen zugeschnitten und bieten optimierte Funktionen für deren Verwaltung. Beispiele umfassen:

   
   

   Container Registry: Plattformen wie Docker Hub oder integrierte Lösungen (z. B. GitLab Container Registry) dienen als zentrale Ablage für Container-Images.

   
   

   npm: Die Standard-Registry für JavaScript- und Node.js-Pakete.

   
   

   PyPI: Die zentrale Plattform für Python-Bibliotheken.

   
   

   NuGet Gallery: Die offizielle Plattform für .NET-Pakete.

   
   

Durch den Einsatz von Artefakt-Repositories werden alle erstellten Artefakte zentral verfügbar gemacht, konsistent verwaltet und können jederzeit für die Bereitstellung oder Weiterentwicklung genutzt werden können.

Das Ergebnis: Release auf Knopfdruck

Mit Continuous Delivery (CD) wird die Softwareentwicklung effizienter und flexibler. Teams können jederzeit ein getestetes und bereitstellungsfähiges Software-Artefakt ausliefern, ohne dass zusätzliche manuelle Schritte erforderlich sind.

Ausblick: Der nächste Schritt zur vollständigen Automatisierung

Mit Continuous Delivery (CD) können Teams jederzeit ein getestetes und bereitstellungsfähiges Software-Artefakt ausliefern. Doch wie wird der gesamte Prozess – von der Codeänderung bis zur Bereitstellung in die Produktionsumgebung – vollständig automatisiert? Im dritten und letzten Teil unserer Serie widmen wir uns Continuous Deployment (CD) und zeigen, wie Teams diesen Schritt zur vollständigen Automatisierung meistern können, um Releases noch schneller und zuverlässiger zu machen.