Gorodenkoff - stock.adobe.com
Tools für das Continuous Deployment von Code
Kontinuierliche Bereitstellung integriert Softwarecode direkt in den produktiven Bereichen. Tools müssen korrekten Code sicherstellen, bevor Fehler auftreten.
DevOps-Organisationen werfen ständig mit dem Wort kontinuierlich um sich – und machen es zum Synonym für schnelle Code-Bereitstellung in produktiven Umgebungen.
Was ist mit kontinuierliche Bereitstellung (Continuous Deployment) gemeint? Kontinuierlich bedeutet, dass Code-Updates direkt und ohne Umwege in den produktiven Bereich des Unternehmens eingehen. Für viele Unternehmen ist dies das ultimative Ziel, aber nur die Wenigsten kommen dorthin. Was kontinuierliche Bereitstellung so schwierig macht, sind die vielen Faktoren, die eine sofortige Code-Integration verhindern. Ein Knackpunkt sind die Tools dafür.
Während die übliche Bereitstellung am Ende einer Pipeline erfolgt, erfordert die kontinuierliche Bereitstellung Tooling-Entscheidungen in allen Phasen: von links – wie zum Beispiel die Versionskontrolle – bis zum Ende der Bereitstellung – und natürlich alle dazwischen liegenden Build- und Test-Services.
Services, die eine Auswahl an kontinuierliche Bereitstellungs-Tools erfordern, können in drei verschiedene Kategorien eingeteilt werden:
- Versionskontrolle;
- Build-Automatisierung mit Tests; und
- Bereitstellung mit Tests.
Tools können in eine oder mehrere dieser Kategorien fallen. Aber um eine kontinuierliche Bereitstellung zu praktizieren, muss eine Organisation alle drei Kategorien abdecken.
Code-Versionen verfolgen
Die Versionskontrolle ist nicht nur eine Voraussetzung für Continuous Deployment – sie ist für fast jedes Softwareprojekt notwendig. Tools für die Versionskontrolle ermöglichen es Entwicklern, Änderungen einzuchecken oder zu übertragen. Diese Änderungen werden dann über die Zeit verfolgt, wodurch Dateinamen wie feature.bak und feature2.bak2 verhindert werden. Die vollständige Versionshistorie ist an jede Datei angehängt, so dass ein Entwickler jederzeit einen bestimmten Zustand des Codes einsehen oder wiederherstellen kann.
Verzweigungsfeatures bei Versionskontrollen ermöglichen es Entwicklern, Kopien einer gesamten Codebasis zu erstellen und mit diesen zu arbeiten. Das Erstellen eines Zweigs ermöglicht es dem Entwickler, so viel von der Codebasis zu ändern, wie er möchte. Er erspart es sich damit, sich Gedanken über die Auswirkungen auf andere Zweige machen zu müssen. Wenn die Änderungen fertig sind, können diese Änderungen wieder mit dem ursprünglichen Quelltext zusammengefügt werden, so dass wieder ein einzelner Zweig entsteht.
Für die Versionskontrolle gibt es verschiedene Tool-Varianten. Git und sein soziales Pendant, GitHub, gehören zu den beliebtesten. Git ist ein lokales Versionskontrollsystem, bei dem Entwickler ein Repository, das manchmal auch Repo genannt wird, auf ihrem lokalen Computer zum Einchecken von Code erstellen. Das Tool bietet alle typischen Funktionen der Versionskontrolle, wie das Einchecken von Code, das Erstellen von Zweigen und das Zusammenführen von Code.
Weil Git Repos sich nur auf dem lokalen Computer eines Entwicklers befinden, wird es auch als verteiltes Versionskontrollsystem bezeichnet. Diese verteilte Natur stellt die Entwickler jedoch bei der Zusammenarbeit vor ein Problem. Alle Git-Repositories synchron zu halten ist schier nicht machbar, deshalb verbindet GitHub diese Git-Repositorys miteinander.
GitHub bietet auch zusätzliche Dienste an. Dazu gehören zum Beispiel Pull-Requests, um Code beizusteuern, Bug- und Feature-Tracking und Dokumentationsspeicherung. GitHub hat Git populär gemacht. Einem Neuling wird es leicht gemacht, mit Git-Repositories anzufangen.
Den Code-Build automatisieren
Sobald der Code in die Versionskontrolle eingecheckt ist, muss er gebaut werden. Der Build-Prozess beinhaltet alle notwendigen Aktionen, um Code und Artefakte in eine nutzbare Software für den Endbenutzer zu packen. Die Aufgaben von Build-Tools bestehen hauptsächlich aus Code-Kompilierung, Paketierung und dem Zusammenführen (Merging) verschiedener Bibliotheken.
Tools für die Build-Automatisierung legen die Schritte zum Erstellen eines Build fest. Jedes Werkzeug erfüllt diese Aufgabe etwas anders, die Grundfunktionalitäten sind jedoch identisch.
Jedes seriöse Build-Automatisierungs-Tool enthält eine Testfunktion. Testmethoden, wie zum Beispiel Unit-Tests, werden typischerweise in dieser Phase ausgeführt. Unit-Tests stellen sicher, dass die letzten Änderungen nicht zu Fehlern geführt haben. Wenn Unit-Tests richtig aufgebaut sind, führen sie den Code in vielen verschiedenen Kontexten aus und betrachten alle Möglichkeiten, wie der Code ausgeführt werden könnte.
Automatisiertes Testen ist wichtig für kontinuierliche Bereitstellungsmodelle, bei denen Code-Updates ohne menschliches Zutun sofort in die Live-Produktion gehen. Bei Continuous Deployment macht der Code vor der Freigabe zu bewertender Operationen Halt.
Was das optimale Build-Automatisierungs-Tool für einen ist, hängt von der Art des Projekts ab. MSBuild ist bei Microsoft-Projekten beliebt. Team Foundation Server und Visual Studio Team Services (VSTS) bieten ebenfalls einige verbreitete Funktionen zur kontinuierlichen Integration. Bei Open-Source-Projekten sind Jenkins, Travis CI und TeamCity beliebt.
Starken Code bereitstellen
Die Bereitstellung ist die letzte und kritischste Phase bei Continuous Deployment. In diesem Stadium nimmt das Tool den Build-Output und liefert diesen an die Produktionsserver oder – im Fall eines Cloud Deployments – aktualisiert eine Produktionsumgebung in der Cloud.
Tools für die kontinuierliche Bereitstellung, Beispiele sind Jenkins, VSTS, Octopus Deploy und AWS CodeDeploy, stellen den Code über Skripte für die Produktion bereit und machen unmittelbar Integrations- und Akzeptanztests. Da dies ein kritischer Moment ist, unterstützen alle Code-Bereitstellungs-Tools mehrere Testverfahren. Deployment Tools ermöglichen es dem Build/Release Engineer oder Entwickler auch, den Code persönlich für die Produktion zu bereitzustellen. Es werden auch sofort eine Reihe von Tests ausgeführt, um sicherzustellen, dass der Code wie gewünscht funktioniert. Diese Tests bestätigen, dass der Code funktionsfähig ist – was manchmal allerdings schwer zu definieren ist.
Die Bereitstellung und Konfiguration erfolgt über IT-Automatisierungs- und Konfigurations-Management-Tools wie Puppet und Ansible. Die Integrations- und Akzeptanztests laufen nach dem Deployment. Monitoring-Tools, wie die von AppDynamics und Splunk, verfolgen und melden alle Änderungen der Anwendungs- und/oder Infrastrukturleistung aufgrund des neuen Codes und können IT Incident Response Management Tools wie PagerDuty auslösen. Die Überwachung und Reaktion auf Vorfälle bei kontinuierlicher Bereitstellung sollte möglichst umgehend und Echtzeit-nah erfolgen, um die Wiederherstellungszeit zu verkürzen.
Für den Fall, dass etwas schief geht, sollte ein gutes Continuous Deployment Tool eine Rollback-Funktion haben. Sie sorgt dafür, dass alle Änderungen rückgängig gemacht werden und zum vorherigen Zustand zurückgekehrt wird.
Kein Risiko, keine Belohnung?
Continuous Deployment ist der schnellste Weg, um Software in die Produktion zu bringen. Es ist aber auch der riskanteste. Tools für die kontinuierliche Bereitstellung eliminieren einen Großteil dieses Risikos. Dafür sorgt in allen Phasen vor allem die integrierte Testunterstützung. Einige senden automatisierte Genehmigungsbenachrichtigungen an die relevanten Akteure. Automatische Genehmigungsanfragen bewegen sich jedoch strenggenommen außerhalb der echten kontinuierlichen Bereitstellungs-Pipeline.
Manche IT-Abteilungen bevorzugen eine Sammlung mehrere Tools, um verschiedene Aspekte der Pipeline zu verwalten. Andere hingegen ziehen es vor, ein Tool für die gesamte Pipeline zu verwenden. Wie auch immer man sich entscheidet: Man sollte bei der Tool-Auswahl die komplette Pipeline, die Unternehmenskultur und die Mitarbeiter berücksichtigen – und auch mit Misserfolgen rechnen.
Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!
