Foto: REDPIXEL.PL - shutterstock.com
Wenn es um Softwareentwicklung geht, liegt der Schlüssel zur Beschleunigung aller involvierten Prozesse in Continuous Integration (CI) und Continuous Delivery (CD). Dabei handelt es sich um eine Sammlung von Prinzipien und Methoden, die Development Teams dazu befähigt, Änderungen am Programmcode schneller, öfter und mit höherer Stabilität vorzunehmen. Im Ergebnis führt das zu einer deutlich schnelleren Reaktion auf Geschäftserfordernisse und Kundenbedürfnisse.
Continuous Integration & Delivery - Definition
Der Begriff Continuous Integration repräsentiert eine Coding-Philosophie sowie ein Methodenset, das geschaffen wurde, um Softwareentwickler bei der regelmäßigen Integration kleinerer Änderungen am Programmcode zu unterstützen. Darüber hinaus können Code-Teile so auf regelmäßiger Basis in Repositories zur Versionskontrolle fließen. Da das Gros heutiger Softwareanwendungen in der Entwicklung verschiedene Plattformen und Tools benötigt, brauchen die Developer einen zuverlässigen Weg, um die Einzelteile miteinander integrieren und Änderungen validieren zu können.
Das Ziel von CI ist es, Software konsistent und automatisiert zu programmieren, zu bündeln und zu testen. Die Konsistenz im Integrationsprozess ermöglicht eine höhere Frequenz von Änderungen am Code, was wiederum zu mehr Kollaboration und am Ende zu höherer Qualität der Applikation führt.
Continuous Delivery schließt nahtlos an Continuous Integration an und beschreibt die automatisierte Auslieferung von Applikationen innerhalb definierter IT-Infrastrukturen. Die meisten Software Developer arbeiten heutzutage mit diversen Entwicklungslandschaften - Continuous Delivery sorgt dafür, dass Code-Änderungen automatisiert über diese heterogene Infrastrukturlandschaft hinweg ausgerollt werden.
Continuous Integration und -Delivery erfordern außerdem Continuous Testing, schließlich besteht das Ziel darin, hochqualitative und durchgängig sichere Applikationen für die Endbenutzer zu schaffen. In Kombination sorgen CI und CD dafür, dass der Prozess der Softwareentwicklung deutlich beschleunigt wird. Continuous Integration und Continuous Delivery werden als Pipeline implementiert. Dabei gilt CI/CD gemeinhin als Best Practice für DevOps Teams.
- CI/CD
Continuous Integration beziehungsweise Continuous Delivery wird oft als essenzieller Teil einer erfolgreichen DevOps-Strategie gesehen. Meist ist die Kombination beider Methoden gemeint, um schneller stabilen Code ausliefern zu können. - Continuous Integration (CI)
Dieser Begriff beschreibt eine Methode, um fortlaufend Veränderungen im Code in den Hauptzweig zu integrieren, die anschließend automatisiert getestet werden. Damit erhalten Entwickler innerhalb weniger Minuten Rückmeldung, ob der Build die Qualitätsansprüche erfüllt. Zudem vermeiden sie den hohen Aufwand, der entsteht, wenn sämtliche Code-Anpassungen auf einmal am Tag der Veröffentlichung in den Release-Zweig integriert werden müssen. - Continuous Delivery (CD)
Dies beschreibt die automatisierte Auslieferung von Anwendungs-Code an diverse Infrastruktur-Umgebungen wie Entwicklungs-, Test, Integrations- und Produktivumgebungen. - Integrated Developer Environments (IDE)
Integrierte Entwicklungsumgebungen sind Anwendungen, die dabei helfen, Anwendung zu bauen. Darin sind normalerweise ein Code-Editor, Compiler, Debugger und Tools zur Build-Automatisierung enthalten, um zeitaufwändige, händische Aufgaben aus der Entwicklung zu entfernen. - Software Development Lifecycle (SDLC)
Es gibt verschiedene Vorgehensmodelle zur Softwareentwicklung, die unterschiedliche Phasen des Software-Lebenszyklus definieren. Die für DevOps verwendeten wiederholbaren Modelle verwenden meist ein kreisförmiges Schema, in denen oft die Stufen Analyse („Was soll die App können?“), Entwurf/Entwicklung, Implementierung, Test und Wartung/Evaluation enthalten sind. - Static Application Security Testing (SAST)
SAST ist eine Methode, um die Sicherheit von Anwendungen während der Entwicklung zu testen. Dabei wird der Quellcode „von innen heraus“ auf Schwachstellen und Bugs hin analysiert. Da der Code für die Analyse nicht kompiliert sein muss, kann SAST sehr früh im Entwicklungszyklus eingesetzt werden, um so Fehler bereits in der Entstehung zu beseitigen. - Regressionstest
In einem Regressionstest werden Testfälle wiederholt, um sicherzustellen, dass Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler („Regressionen“) verursachen.
Der Trend zur CI/CD Pipeline
Nach Einschätzung von Branchenexperten setzen immer mehr Unternehmen auf Continuous Integration und Continuous Delivery, um Design, Entwicklung und Auslieferung von Softwareprodukten schneller und effizienter zu gestalten. Insbesondere in Unternehmen, die auf agile Softwareentwicklung setzen, ist das der Fall, wie ein Blick auf die Gartner-Umfrage "Agile in the Enterprise" zeigt.
Demnach weisen agile Entwicklungsteams eine deutlich erhöhte Adoptionsrate von CI/CD auf: "Meiner Meinung nach ist Continuous Integration der natürliche Startpunkt für die Schaffung von automatisierten Pipelines", sagt Sean Kenefick, Analyst bei Gartner. "Die etwas diffizileren Aspekte von Continuous Delivery werden für automatisiertes Testing und die Re-Architektur von Software benötigt."
Serverless Computing, steigende Security-Anforderungen und der Agile-Trend haben CI/CD inzwischen zu einer Mainstream-Strategie für alle Unternehmen erhoben, die etwas mit Softwareentwicklung zu tun haben: "Features wie Continuous Integration, automatisiertes Testing und Continuous Delivery wurden früher nur von hippen Startups angeboten. Inzwischen bedienen sich auch traditionelle (Groß-)Unternehmen erfolgreich dieser Methoden", weiß Hasan Yasar, Direktor am Software Engineering Institute der Carnegie Mellon University.
Im Folgenden geben wir Ihnen einige Tipps an die Hand, wie Sie eine nachhaltige CI/CD-Strategie in Ihrem Unternehmen implementieren.
CI/CD braucht Stakeholder
Eine möglichst frühe Einbeziehung aller an einem Entwicklungsprojekt beteiligten Stakeholder ist für den Erfolg einer CI/CD-Strategie essenziell, wie Yasar weiß: "Der maßgebliche Benefit entsteht durch die Beteiligung aller Stakeholder in jeder Phase eines Entwicklungsprojekts, bei der Entscheidungen getroffen werden. Die IT sollte beispielsweise einbezogen werden, wenn es um die Architektur geht, damit die Entwickler auf einer Plattform arbeiten, die von vorneherein allen Anforderungen der IT genügt."
Dieses Muster sollte bei allen wesentlichen Projektentscheidungen mit allen relevanten Stakeholdern wiederholt werden. So ist sichergestellt, dass jede große Entscheidung unter Beteiligung von Experten gefällt und die im Rahmen des Projekt-Lebenszyklus üblicherweise entstehenden, technischen Schulden auf ein Minimum reduziert werden.
Das richtige CI/CD-System
Die auf dem Markt erhältlichen Systeme für Continuous Integration und Continuous Delivery können Unternehmen ganz konkrete Vorteile verschaffen. Der Einsatz solcher Systeme ist nach Überzeugung von DevOps Engineer Josh Komoroske vom Security-Anbieter StackRox auch ein Signal dafür, wie gesund eine Entwicklungsabteilung ist: "Wenn es zum Kinderspiel wird, neue Features zu integrieren, zu testen und auszurollen, erhöht sich die Reaktionsfähigkeit einer Organisation auf Veränderungen drastisch. Dauert es hingegen Wochen oder Monate, ihren Kunden etwas zu liefern, kommt ein anderes Unternehmen, dass es schneller und besser kann."
Wenn es darum geht, die entsprechende Software auszuwählen, sollten Unternehmen jedoch vor allem gewissenhaft recherchieren, so der Experte weiter. Die eingehende Analyse des vorhandenen Ökosystems und der hierfür verfügbaren Lösungen sei dazu genau so unerlässlich, wie die Einbindung der Softwareentwickler. Schließlich sind sie es, die das CI/CD-System im Tagesgeschäft nutzen sollen. Ist die Entscheidung für das CI/CD-System gefallen, sollten Unternehmen alles daransetzen, dessen Vorteile klar herauszustellen: "Setzen Sie das System auf und demonstrieren Sie anhand konkreter Beispiele, wie es funktioniert", rät Komoroske. "Wenn die Menschen sehen, dass es einen Mehrwert für ihre Workflows bringt, wird das Ganze zum Selbstläufer."
Continuous Integration & Delivery Tools
Continuous Delivery Tools decken laut Gartner im Wesentlichen vier Bereiche ab:
Neuaufbau für Isolationszwecke;
Automatisiertes Testing;
Schaffung einer automatisierten Prozess-Pipeline;
Automatisierte Bereitstellung und Konfiguration von Umgebungen;
Diese Komponenten sind allgemein gehalten und können viele individuelle Prozesse nach sich ziehen, um eingesetzt werden zu können. Um beispielsweise automatisiertes Testing zu realisieren, müssen jeweils eigene Sets für Performance- und Security Testing erzeugt werden. Außerdem sind auch automatisierte Tests notwendig, die die IT-Umgebungen und Orchestrierungs-Plattformen hinsichtlich ihrer korrekten Konfiguration überprüfen. "Es gibt dabei keinen Aspekt, der wichtiger ist als der andere - alle sind von gleicher Bedeutung", sagt Gartner-Analyst Kenefick.
Unternehmen sollten dafür sorgen, dass manuelle Zulassungsprozesse an kritischen Stellen im Deployment-Prozess zum Zuge kommen. Diese verhindern, dass ungetesteter oder nicht freigegebener Programmcode in Produktions- oder Testumgebungen gelangt. Darüber hinaus ermöglicht dieses Vorgehen eine bessere Kontrolle darüber, wann der Code für Schlüssel-Umgebungen freigegeben wird.
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
Metriken für den CI/CD-Erfolg
Wie bei den meisten anderen Technologien und Prozessoptimierungen ist auch im Fall von Continuous Integration und Continuous Delivery nicht damit getan, einmal etwas aufzusetzen und dann die Füße hochzulegen. Einblicke in verschiedene Metriken des "Build/Test/Deploy"-Zyklus sind unabdingbar für die effiziente Optimierung von CI/CD Tools.
Diese Tools sollten für Unternehmen Multiplikatoren darstellen und sowohl Entwicklungs- als auch Testzeiten und die Time-to-market reduzieren. Deshalb ist es unerlässlich, die Verbesserungen von CI/CD Tools zu erfassen und diese im Zeitverlauf miteinander zu vergleichen.
Was Continuous Integration & Delivery bringt
Damit das Entwicklungsteam in einem Unternehmen die notwendigen Kompetenzen aufbauen kann, um eine CI/CD-Strategie erfolgreich zu fahren, sollten Unternehmen verstehen, warum genau sie Continuous Integration und Continuous Delivery brauchen. Diese Vorteile können erschlossen werden:
Verbesserte Produktivität der Softwareentwickler
Optimierung des Delivery Frameworks
Verbesserte Prozesseffizienz
Agile Transformation
Frühe CI/CD-Plattformen wurden als Orchestrierungs-Services konzipiert, die Prozesse rund um den Produkt-Lebenszyklus miteinander verbinden, um die Produktivität zu erhöhen. Mit der Zeit, die die Entwicklung des Programmcodes in Anspruch nimmt, steht und fällt allerdings auch der Return on Investment.
Farid Roshan, Chef-Entwickler beim Softwareanbieter Altimetrik, weiß worauf es bei modernen CI/CD-Initiativen ankommt: "Sie sind auf modulare IT-Architekturen anpassbar, erlauben 'plug and play'-Verfahren und ermöglichen es, die Pipeline so zu konfigurieren, dass sie diverse Delivery Frameworks unterstützt. Nur wenn die Pipeline auch richtig implementiert wird, ist dafür Sorge getragen, dass die Softwareentwickler erweiterte Funktionalitäten schaffen können, die den aktuellen Geschäftsanforderungen entsprechen."
Dabei, so der Experte weiter, sei es aber auch wichtig, künftige Anforderungen zu antizipieren: "Entwickeln Sie CI/CD-Fähigkeiten für Ihre zukünftigen Business-Ziele. Die Adoption eines CI/CD-DevOps-Ansatzes innerhalb von Silo-Strukturen und auf Basis existierender Prozesse führt zu Fragmentierung, einem Mangel an Standardisierung und einem minimalen ROI hinsichtlich Agilität. Das kann einen Kaskadeneffekt für das gesamte Unternehmen nach sich ziehen."
Automatisierung mit CI/CD
Im Rahmen einer Continuous-Integration- und Continuous-Delivery-Strategie sollten Unternehmen alle Prozesse automatisieren, bei denen das sinnvoll ist. Dabei sollten Aspekte, die sich nicht automatisieren lassen, klar herausgestellt werden, empfiehlt Hasan Yasar: "Automatisierung ist ein Grundpfeiler von DevOps und gleichzeitig einer der wesentlichen Benefits einer DevOps-Implementierung, die auf CI/CD Enablement abzielt."
Der agile DevOps-Ansatz, den das SEI empfiehlt, wird durch "Infrastructure as a Code" (IaC) ermöglicht. Darunter versteht man das Management von Infrastruktur-Komponenten (etwa Netzwerke, virtuelle Maschinen oder Load Balancer) unter Anwendung derselben Versionierungs-Methoden, die DevOps Teams bei der Erstellung von Quellcode nutzen. Darüber hinaus werden hierbei diverse Umgebungen automatisiert: "Das Ziel ist, alle automatisierten Prozesse wie Programmcode zu behandeln. Dieser wird in einem abgesicherten Versionskontrollsystem vorgehalten", erklärt Yasar.
Dabei ist der Infrastruktur-Code im selben Repository abgelegt wie der Applikations-Code. So haben sowohl die Entwickler als auch alle Stakeholder jederzeit Zugriff.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.