Zu den Schlagwörtern des IT-Zirkus der vergangenen Jahre, die bei vielen Verantwortlichen regelmäßig genervtes Augenrollen auslösen, gehört ohne Zweifel der Begriff "DevOps". Das Kofferwort aus "Development" und "Operations" beschreibt einen Ansatz, der in vielen Firmen an den ehernen Grundsätzen der Unternehmensstruktur rüttelt – vor allem an der Maxime, dass Entwicklung und Administration einer Anwendung in getrennten Abteilungen voneinander zu passieren haben.

Das ist vielerorts noch immer die Regel: Die Entwicklungsabteilung baut vor sich hin und veröffentlicht – oft zu festen Terminen – eine neue Version einer Anwendung, die dann den Weg in die Produktion finden muss. Diesen Teil der Arbeit übernehmen die Admins, die ebenfalls an einem zuvor definierten Termin ("Wartungsfenster") das Update einspielen und danach prüfen, ob alles funktioniert. Es würde an dieser Stelle den Rahmen sprengen, Dev-Ops im Detail zu erklären. Nur so viel sei deshalb gesagt: Unternehmen erhoffen sich vom DevOps-Ansatz vor allem, dass sie ihre firmeninternen Silos loswerden, bei denen Entwickler und Admins kaum wissen, was die jeweils andere Partei tut. Die Dynamisierung der Entwicklung soll zu kürzeren Release-Zyklen mit weniger neuen Features führen, bei denen dann, so die Hoffnung, insgesamt auch weniger kaputt geht. Im Fachjargon firmiert dieses Konzept auch unter dem Namen "Continuous Integration, Continuous Development" (abgekürzt üblicherweise mit "CI/CD").

Rund um das DevOps-Prinzip ist in den vergangenen Jahren ein riesiger Markt von Werkzeugen entstanden, die Unternehmen bei der Umsetzung von DevOps-Prinzipien unterstützen wollen. Octopus Deploy ist eines davon: Die Software hilft Unternehmen dabei, fertige Anwendungen in die Produktion zu bringen, dabei kontinuierlich zu überwachen und auf Wunsch externe Tools einzubinden, die automatisiert die Qualität der Dienstleistung überwachen. Das ist kein neuer Ansatz, und "CI/CD-Toolchains" lassen sich mit Werkzeugen wie Jenkins seit Jahren gut erstellen. Doch das Beispiel Jenkins zeigt auch, dass derartige Tools in mancherlei Hinsicht komplex und schwierig in der Handhabung sind. Octopus Deploy verspricht hingegen so einfach bedienbar zu sein, dass sogar relativ unerfahrene Anwender mit der Software Anwendungen in Produktion bringen können. Wir knüpfen uns die Software deshalb vor und untersuchen sie im Hinblick auf fünf Kriterien.

Zunächst steht die Frage im Vordergrund, ob das Programm im Hinblick auf seine Grundfunktionen hält, was der Anbieter verspricht. In Zeiten von mannigfaltigen Deployment-Zielen (von "lokaler VM" bis "Amazon AWS" ist praktisch alles möglich) stellt sich die Frage, welche externen Zielsysteme Octopus Deploy unterstützt. Dann spielen wie üblich die Themen Security und Compliance eine Rolle und der Beitrag, den Octopus zu diesem Themenkomplex liefert. Weiter geht es mit der Frage, wie gut sich Octopus mit artverwandten Werkzeugen verknüpfen lässt, etwa durch fertige API-Integrationen. Und nicht zuletzt kommt das Octopus-Versprechen unter die Lupe, den Admin auch nach einem Deployment mit diesem nicht allein zu lassen, sondern umfassende Analyse- und Monitoringoptionen anzubieten.

Anders als vergleichbare Lösungen ist Octopus eine eher monolithische Software. Der IT-Verantwortliche hat die Wahl, ob er das Werkzeug in der Octopus-Cloud oder in seinem Rechenzentrum (on-premises) betreibt. Die Installation ging bei uns leicht von der Hand, und unmittelbar danach war Octopus schon einsatzbereit – dann stand aber noch die Grundkonfiguration an.

Um diese erfolgreich zu meistern, muss sich der Admin zunächst mit ein paar Begriffen aus dem Octopus-Universum vertraut machen. Von zentraler Bedeutung sind zunächst die "Environments", also die Umgebungen. Diese sind in Octopus Deploy logische Einheiten, und üblicherweise nutzen Admins Umgebungen, um zwischen unterschiedlichen Deployment-Zielen wie "Testing", "Staging", "Produc-tion" oder "Development" effektiv zu unterscheiden. Wer Octopus im eigenen RZ betreibt, findet in diesem nach der initialen Konfiguration gar keine Umgebungen vor, kann diese also nach eigenem Gutdünken komplett beliebig definieren.

Innerhalb einer Umgebung gibt es als Untereinheit das "Projekt" (Bild 2). Projekte sind wieder beliebig definierbar, die Entwickler empfehlen allerdings, logisch zusammengehörende Softwarekomponenten innerhalb eines Projekts zu summieren. Wichtig: Pro Projekt lässt sich nur ein Satz von Anweisungen für das Deployment hinterlegen. Dieser kann dann zwar wiederum beliebig viele Befehle enthalten. Doch der Admin muss sich im Vorfeld vor Augen halten, dass er beim Zusammenfassen mehrerer Anwendungen in einem Projekt zu einer Gruppe alle aus denselben Anweisungen heraus ausrollen muss. Enthält ein Projekt nur eine monolithische App, ist das in der Regel kein Problem. Kommt hingegen eine typische, nach den Regeln der "Cloud Ready"-Lehre gebaute Architektur mit vielen winzigen Mikroapplikationen zum Einsatz, wird die Summe der Deployment-Steps unter Umständen schnell unübersichtlich. Sind Umgebung sowie Projekt angelegt, konnten wir festlegen, welche Aufgaben zum "Deployment" gehören. Im einfachsten Beispiel, das lediglich ein "Hello World" ausgibt, genügte hierfür ein einzelner Kommandozeilenbefehl.

In der Realität werden die Deployment-Anweisungen freilich viel komplexer sein und aus vielen einzelnen Schritten bestehen. In genau diese teilt Octopus das Deployment entsprechend ein, und wie beschrieben kann ein Projekt fast beliebig viele Deployment-Schritte umfassen. Auch im Hinblick auf die Wahl seiner Mittel ist der Admin kaum beschränkt: Neben Shell-Skripten steht hier auch die Integration etlicher zusätzlicher Werkzeuge parat, auf die wir später noch im Detail eingehen.

Wichtig ist den Octopus-Entwicklern ausdrücklich, dass die GUI in ihrer Lösung kein stiefmütterliches Dasein fristet, sondern integraler Teil ist. Zwar lässt Octopus Deploy sich auch per Kommandozeile steuern, doch anders als viele andere CI/CD-Werkzeuge steht hier die grafische Oberfläche im Vordergrund.

Die Macher der Software erhoffen sich davon vor allem, die Einstiegshürde in das CI/CD-Konzept insgesamt zu senken und seine Vorteile auch Kollegen in Unternehmen verfügbar zu machen, die nicht kommandozeilenfest sind. Ein Paradebeispiel könnte der Helpdesk oder die Support-Abteilung sein, die im Kundenauftrag ein Problem lösen, ohne sonderliche Shell-Erfahrung zu haben.

Doch wie realistisch ist das wirklich? Wir möchten anhand eines Beispiels darlegen, dass der Ansatz durchaus funktionieren kann. Gegeben sei eine Anwendung, die ein Unternehmen im Kundenauftrag betreut und die wegen erhöhter Last am Wochenende zusätzliche Ressourcen braucht. Indem der Helpdesk die Eigenschaften des Rollouts in Octopus Deploy anpasst (und insbesondere mehr "Worker"-Knoten konfiguriert), lässt sich diese Anforderung sehr leicht erfüllen. Mehr noch: Selbst wenn es nötig werden sollte, die Konfiguration einer Anwendung anzupassen, ist das keine unüberwindliche Hürde.

Das gilt zumindest dann, wenn die Anwendung ihre Konfiguration – wie es heute Standard sein sollte – in Git verwaltet ("GitOps"). Auch ohne tiefgreifende Git-Erfahrung ist es Helpdesk-Mitarbeitern durchaus möglich, Dateien in Git zu aktualisieren – etliche externe GUIs machen das möglich. Ist ein Git-Verzeichnis dann per Hook mit Octopus Deploy verbunden (auch dazu später mehr), passiert nach der Änderung in Git das Redeployment automatisch und anhand fester Grundsätze. Das ermöglicht nicht nur Helpdesk-Mitarbeitern, Aufgaben zu erledigen, ohne sich großartig mit Linux-Interna zu befassen, sondern verkürzt auch die Dauer, die solche Änderungen beanspruchen.

Insgesamt leistet sich Octopus Deploy bei den Grundfunktionen keine Schnitzer und liefert, was versprochen ist. Das sehr funktionale und obendrein optisch sinnvoll gestaltete und ansprechende GUI beschert der Software einen Extrapunkt in der Bewertung der Grundfunktionen.

Die schönste CI/CD-Lösung ist nichts wert, wenn sie nicht in der Lage ist, die konfigurierten Workloads dort zu starten, wo diese laufen sollen. Ein zentraler Aspekt bei der Beurteilung der Funktionen von Octpus Deploy ist daher die Frage, welche Deployment-Ziele das Produkt ab Werk unterstützt und wie gut dies umgesetzt ist. Es ist beispielsweise nicht sonderlich schwer, eine einzelne Instanz in AWS zu starten, sich mit deren IP-Adresse zu verbinden und Anwendungen zu installieren. Sollen aber PaaS-Features eines Hyperscalers zum Einsatz kommen oder Container in Kubernetes bei Bedarf auch mit einer speziellen Konfiguration ausstattbar sein, muss das Deployment-Werkzeug auch damit umgehen können.

Art und Umfang der von Octopus Deploy unterstützten Ziele sind am besten mit "Hausmannskost" zu umschreiben. Einzelne Deployment-Ziele legten wir in der GUI von Octopus an, wobei wir für jedes dieser Ziele einen Typ definierten. Als generische Typen stehen Linux-Server mit SSH-Verbindung zur Verfügung. Diese sind allerdings nicht die erste Wahl, denn Octopus liefert eine eigene Komponente namens "Tentacle" mit. Das ist eine Art Agent, der auf Deployment-Zielen Befehle von Octopus entgegennimmt und in lokale Systemkonfiguration umsetzt. Tentacle steht für Windows wie Linux zur Verfügung, womit auch geklärt wäre, welche Ziel-Betriebssysteme Octopus Deploy grundsätzlich betankt.

Erwähnt sei, dass durch Tentacle bereits eine große Viezahl von Deployment-Targets realisiert ist. Denn ein generischer Linux- oder Windows-Server kann ja auch eine virtuelle Instanz in einer bestehenden Proxmox-Instanz sein, die der Admin eigens für Octopus aus dem Boden stampft.

Etwas abstrakter geht es zu, wenn Octopus Dienste in Cloudumgebungen ausrollen soll. Hier gibt es zudem Unterschiede bei der Qualität der Implementierung der Azure-Cloud und AWS. Denn für Azure unterstützt Octopus Deploy auch dessen Services-API, über die sich einzelne Azure-Dienste unmittelbar starten lassen. Für AWS mussten wir in Octopus hingegen lediglich einen Satz von Zugangsdaten angeben und hatten im Nachgang die Option, direkt aus Octopus heraus EC2-Instanzen zu starten. Sollen spezielle AWS-Dienste wie DBaaS zum Einsatz kommen, legt der Systemverwalter besser ein CloudFormation-Template an und weist Octopus an, dieses an die AWS-API zu verfüttern. Im Ergebnis erhält der Admin bei Azure wie AWS vergleichbare Dienste, muss bei AWS aber etwas Eigenleistung erbringen.

Octopus selbst sieht übrigens eine Kategorie namens "Cloud Regions" vor. Mittels dieser lassen sich die konfigurierten Deployment-Targets in geografische Gruppen einteilen. Wählten wir im Test anschließend als Deployment-Target für eine Anwendung eine solche Region aus, führte Octopus das Deployment in verschiedenen Bereichen oder auf verschiedenen Zielen innerhalb dieser Region aus.

Kubernetes und kein Ende: Weil ein Artikel über ein Cloudwerkzeug ohne Kubernetes unvollständig wäre, ist festzustellen, dass auch Kubernetes ein Ziel für Octopus Deploy sein kann. Octopus kommuniziert dabei unmittelbar mit der Kubernetes-API und legt die Ressourcen wie in der Beschreibung des Deployments angegeben an. Den größten Teil der Features von Kubernetes unterstützt Octopus Deploy dabei, bei lokalen Abweichungen von der Norm etwa in Form von Custom Resource Definitions (CRDs) kann es aber zu Schwierigkeiten kommen.

Insgesamt kommt Octopus bei diesem Kriterium also nicht ins Schleudern. Alle Deployment-Ziele, die von einer modernen Software dieser Art ab Werk zu erwarten sind, stehen zur Verfügung. Für Tentacle gibt es einen Extrapunkt, weil Octopus darüber sehr effizient in der Lage ist, die Zielsysteme passend vorzubereiten.

Nicht zuletzt die DSGVO hat dafür gesorgt, dass selbst kleine Firmen sich über Rechtemanagement umfassend Gedanken machen. Denn wenige Aspekte sind in der DSGVO so klar und grundsätzlich geregelt wie die Tatsache, dass auf Daten nur jene Zugriff haben dürfen, die diese auch tatsächlich benötigen. Es ist stellenweise allerdings alles andere als trivial, diesen Anspruch umzusetzen. Und praktisch nie kommt der IT-Verantwortliche ohne eine zentrale Benutzer-, Rechte- und Rollenverwaltung aus. Dienste wie Octopus Deploy sind keine Ausnahme: Auch hier werden Helpdesk-Mitarbeiter regelmäßig Zugriff auf andere und weniger Daten haben als die Systemadministratoren selbst. Ein Dienst wie Octopus muss in der Lage sein, ein solches Rechteschema abzubilden.

Dazu lässt sich Octopus mittels einer Vielzahl verschiedener Nutzer- und Rechteverzeichnisse im Hintergrund verbinden. Neben dem obligatorischen LDAP steht Active Directory in der Azure Cloud ebenso zur Verfügung wie die Login-Verwaltung mittels GitHub-Nutzern. Das Rechtekonzept kann Octopus dabei wahlweise selbst implementieren, sodass der Nutzer auf Octopus-Ebene festlegt, wer was darf. Alternativ lässt sich ein Rechtekonzept aber auch aus dem Benutzerverzeichnis vererben, sodass einzelne Gruppen und Rollen auf der Octopus-Ebene mit den passenden Berechtigungen unterwegs sind.

Konkret konnten wir den Zugriff auf jede Umgebung explizit steuern. Entwickler ließen sich so auf die Staging- und Dev-Umgebungen limitieren, während der Helpdesk von eben diesen die Finger zu lassen hatte und nur bestimmte Änderungen in der Produktionsumgebung durchführen durfte. Insgesamt schlägt Octopus sich hier sehr gut; insbesondere die native Anbindung an das Azure Active Directory findet sich nicht regelmäßig bei vergleichbaren Lösungen.

Ein elementarer Bestandteil des DevOps-Prinzips, das Octopus konsequent umsetzt, ist: Sobald ein Deployment in Produktion gegangen ist, endet die CI/CD- Toolchain nicht – sie bekommt nur andere Aufgaben. Dazu gehört die Überwachung der vorhandenen Dienste mittels verschiedener Analyse- und Metrikfunktionen. Octopus geht hier clever vor: Mittels der so genannten Runbooks (Bild 4) waren wir analog zu den Deployment-Schritten in der Lage, Aufgaben zu definieren, die Octopus immer wieder in bestehenden Deployments anwendet. Der Fantasie sind dabei kaum Grenzen gesetzt; alles, was sich in einer Funktion maschinell darstellen lässt, kann Bestandteil eines Runbooks sein.

Wann Runbooks laufen sollen, definierten wir mittels sogenannter Trigger. Ein regelmäßiger Trigger für ein Deployment mit Datenbank könnte etwa sein, alle 30 Minuten einen Dump der Datenbank zu ziehen, zu komprimieren und verschlüsselt in einem externen Backupsystem zu speichern, beispielsweise Amazons S3. Auch Ad-Hoc-Runbooks sind denkbar: Pfeift die Datenbank wegen eines Konsistenzproblems aus dem letzten Loch, könnte ein Runbook sie reparieren – und zwar eines, das nur eine befugte Person starten darf. Welche konkreten Befehle sich jeweils genau hinter diesen Aufgaben verbergen, ist der Fantasie des Admins vorbehalten.

Zuletzt beschäftigten wir uns im Test mit der Frage, wie gut sich Octopus mit anderen Lösungen aus der CI/CD-Sphäre verheiraten lässt. Hier gebührt den Entwicklern Lob und Anerkennung, denn wenige Werkzeuge am Markt sind so versatil wie Octopus. Per Webhook ließ sich etwa ein GitLab- oder GitHub-Verzeichnis mit Octopus verdrahten, so dass eine Änderung in Git automatisch Prozesse in Octopus in Gang setzte.

Dabei unterstützt die Software diverse Skript- und Programmiersprachen. Ruby, Python oder Go kennt Octopus, interpretiert sie richtig. Zudem findet sich eine exzellente Unterstützung in Build-Servern wie Jenkins oder TeamCity, für die Octopus ebenfalls eine Andockmöglichkeit vorsieht. Der Admin muss in Octopus also nicht zwangsläufig "nur" ein Shell-Skript hinterlegen, um den Bauvorgang einer Umgebung nach einem Git-Commit zu starten. Er kann stattdessen auch auf Artefakte zurückgreifen, die zuvor aus Git initiiert wurden und dann durch Jenkins oder TeamCity gewandert sind. Liegt die fertige Anwendung einmal bei Octopus, kümmert dieses sich darum, die Anwendung auszurollen.

Bei Bedarf lässt sich auch noch eine lokale Registry etwa für Docker-Abbilder oder Skriptsprachen-Artefakte in den Kreislauf integrieren. Das ist gerade in Umgebungen, in denen Compliance eine große Rolle spielt, oft notwendig. Dabei kann Octopus selbst in Kombination mit Diensten wie Git und TeamCity auch zum Einsatz kommen, um das Abbild zu erstellen und in eine Container-Registry zu laden. Dabei wird klar: Eine "laufende Applikation" kann auch ein erstelltes und in die lokale Registry geladenes Docker-Abbild sein, dessen Funktionalität sich danach per Runbook regelmäßig überprüfen lässt. Der Funktionsumfang und die Vielseitigkeit von Octopus nötigen DevOps-Fans mithin einigen Respekt ab.

Die Arbeit mit Octopus macht Spaß. Das Programm ist leicht zu nutzen, schnell zu installieren und dank seiner intuitiven grafischen Oberfläche auch für Personen verwendbar, die nicht etliche Lenze der Administration von Linux-Servern auf dem Buckel haben. In keiner der Kategorien dieses Tests leistete Octopus sich tatsächliche Schwächen. Im Gegenteil: Die feilgebotenen Features, die der Hersteller verspricht, sind im Programm vorhanden und funktionieren.

Dass sogar Sonderlocken wie die Authentifizierung mit Azure AD das Tool vor keine großen Herausforderungen stellen, rundet den insgesamt sehr positiven Gesamteindruck ab. Wer eine CI/CD-Toolchain einführen oder verbessern möchte, sollte sich Octopus jedenfalls sehr genau anschauen. Es gehört zu den wirklich nützlichen Suiten am Markt, die auch manche DevOps-Zweifler zu überzeugen vermögen.