Agil 2.0 - DevOps in der Softwareentwicklung

Der Begriff DevOps setzt sich aus den beiden folgenden Wörtern zusammen: Dev steht für Development (englisch für Entwicklung) und das Ops für Operations (IT-Betrieb). Beide Begriffe vereint stehen für einen Prozessverbesserungsansatz aus Softwareentwicklung und IT-Betrieb.

Das Ziel ist Menschen, Prozesse und Technologien zu vereinen, damit kontinuierlich hochwertige Produkte geliefert werden. DevOps steht für die Möglichkeit, in kurzen Intervallen ein Softwareprodukt auszuliefern. Durch ein besseres Zusammenspiel zwischen Softwareentwicklung und IT-Betrieb ist es möglich, die Softwareentwicklung zu beschleunigen und die Qualität der Produkte zu verbessern.

Auf den ersten Blick scheint DevOps rein technologisch getrieben zu sein, doch alles beginnt mit der Kultur in der Organisation und mit den Personen, die an den Prozessen mitwirken. Für die Einführung einer DevOps-Kultur sind weitreichende Änderung an der Arbeitsweise und Zusammenarbeit der Mitarbeiter nötig. Wir bei M&M haben durch die Einführung der DevOps-Kultur, zusammen mit dem agilen Softwareentwicklungsprozess, leistungsfähigere Teams etabliert:

"Durch die Automatisierung hat sich die Fehlerrate reduziert und wir sind in der Lage schneller und effektiver Software zu liefern"

 Daniel Marcek, Group Leader, Business Unit Software Applications bei M&M

Einer der wichtigsten Faktoren in der DevOps-Kultur ist die Zusammenarbeit der Teams. Die Entwicklung und der IT-Betrieb müssen dabei ihre DevOps-Prozesse, Prioritäten und Zuständigkeiten einander offenlegen und sichtbar machen.

Zuvor getrennte Rollen wie Softwareentwicklung, IT-Betrieb, Qualitätskontrolle und Sicherheit vereinen und koordinieren sich im DevOps-Team. Wo früher der Softwareentwickler rein für die Entwicklung der Software zuständig war, erweitert sich das Spektrum seiner Zuständigkeit in Richtung IT-Betrieb.

DevOps-Teams sind flexibel, da die Software in kurzen Zyklen veröffentlich wird. Durch kürzere Releasezyklen werden auch die Planung und das Risikomanagement vereinfacht, da es sich um einen inkrementellen Prozess handelt und so permanent nachjustiert werden kann. Durch den kurzen Feedback-loop vom Kunden kann sehr schnell auf die geänderten Anforderungen reagiert werden, um so einen Wettbewerbsvorteil zu schaffen.

Durch das Einführen der agilen Ideen in den Software-Lebenszyklus wurde bei M&M die Möglichkeit geschaffen, Softwarelieferungen in sehr kurzen Intervallen bereitzustellen. Durch das Vertrauen in die Fähigkeiten des Teams, die bestmögliche Lösung zu finden, wurden enorme Potenzale geweckt. Dieser Kulturwandel in der Softwareentwicklung ermöglicht eine größere Identifikation des Teams mit dem Produkt, reduziert die Releasezyklen und erhöht dabei die Softwarequalität.

1. produktiver / effizienter
2. Automatisierung reduziert manuelle Fehler
3. kürzere Releasezyklen
4. höhere Kundenzufriedenheit
5. kürzere Feedbackschleife
6. kontinuierlicher Informationsfluss

Der kontinuierliche DevOps-Zyklus sieht folgende Methoden und Praktiken vor:

• Plan
  Agile Planung und Projektmanagement werden genutzt, um Arbeitsschritte in Sprints aufzuteilen, Kapazitäten des Teams zu verwalten und Teams an sich verändernde Geschäftsziele anzupassen. In der Planungsphase werden die Ideen zu neuen Features und Eigenschaften der Anwendung (bzw. des Systems) gesammelt, diese definiert und beschrieben. Das Tracking von Fortschritten auf niedriger sowie hoher Granularität, z. B. einzelner Tasks oder ganzer Portfolios von mehreren Produkten, trägt in dieser Phase zur stetigen Verbesserung bei.
• Code
  Anhand des in der vorherigen Phase erstellten Plans werden die neuen Features bzw. Eigenschaften der Anwendung oder des Systems implementiert. Hierzu gehören neben dem Schreiben des Codes und Unit-Tests auch das Code-Review sowie die Integration mit dem Code anderer Teammitglieder.
• Build
  Continuous Integration (CI) ist schon lange ein etablierter Begriff in der Softwareentwicklung und spielt auch bei DevOps eine wichtige Rolle. In dieser Phase werden wohlgeformte Build-Definitionen genutzt, um den geschriebenen Code in einer Pipeline zu übersetzen, per Unit-, Integrations- oder End-to-End Tests zu validieren und mit statischer Codeanalyse zu analysieren. Falls der Build fehschlägt, die Tests Fehler melden oder die Code-Qualität nicht den Projektstandards entspricht, wird die gesamte Pipeline fehlschlagen und der für die Änderungen verantwortliche Entwickler benachrichtigt, um seinen Code zu korrigieren/ verbessern. Alle Schritte in dieser Phase sollten vollständig automatisiert stattfinden und bei jeder Änderung des Codes im Repository ausgeführt werden. Das Ergebnis dieser Phase sind ein oder mehrere versionierte und deploy-, integrier- bzw. ausführbare Build-Artefakte sowie KPIs zu Code-Qualität und Testabdeckung.
• Test
  Sobald neue Build-Artefakte aus der Build-Phase erzeugt werden, können diese - idealerweise wieder vollständig automatisiert - in eine Test- oder Staging-Umgebung deployed werden. Diese Umgebungen können entweder bereits existieren, d.h. in jedem Zyklus wiederverwendet, oder speziell für diese Phase neu aufgesetzt werden. Letzteres ist durch Methodiken, wie Infrastructure as Code (IaC), ebenfalls automatisiert durch eine Pipeline abbildbar. Gegen diese Test- oder Staging-Umgebung können dann manuelle Tests, wie z. B. Akzeptanztests sowie automatisierte Tests ausgeführt werden. Unter den automatisierten Tests können sich bspw. UI-Tests befinden, aber auch Security-Scanner, die die Umgebung nach Lücken, wie z. B. ungewollt geöffneten Ports, untersuchen.
• Release
  Die Release-Phase ist ein Meilenstein des DevOps-Zyklus. Der Code, bzw. die Build-Artefakte, die es bis hier hingeschafft haben, ist nun erfolgreich durch eine Reihe von Analysen und Tests gelaufen und damit bereit für das Deployment in eine Produktivumgebung. Je nachdem, wie stark DevOps in einer Organisation gelebt wird, kann diese Phase auch automatisiert nach der Testphase ablaufen. Alternativ können hier auch manuelle Approvals von Product-Owner, Projekt- oder Produktmanager die weiteren Schritte anstoßen.
• Deploy
  Hier wird die Anwendung nun in das Produktivsystem deployed und live geschalten. Mit Infrastructure as Code wird gewährleistet, dass sich die Produktivumgebung (bis auf die Konfiguration) nicht von der Test- oder Staging-Umgebung unterscheidet. So können grundlegende Fehler in der Infrastruktur vermieden werden. Durch Deployment-Strategien, wie z. B. ein Blue/Green Deployment, kann das Veröffentlichen einer neuen Version der Anwendung ohne Downtime erfolgen. Falls trotz ausführlicher Tests in den vorherigen Phasen doch noch ein kritischer Bug in der neuen Version des Produktivsystems auffällt, kann damit sogar binnen Sekunden wieder auf die alte Version zurückgeschalten werden.
• Operate
  Nachdem die Änderungen produktiv sind, muss ein störungsfreier Betrieb sichergestellt werden. In dieser Phase werden Ressourcen anhand der Auslastung der Anwendung skaliert, die dauerhafte Verfügbarkeit sichergestellt und auf Supportanfragen von Kunden reagiert.
• Monitor
  Dies ist zwar die finale Phase des DevOps-Zyklus, sollte aber über alle Phasen hinweg betrieben werden. Zum einen muss die Anwendung selbst überwacht werden, sodass Feedback bzgl. neuen Features oder Systemeigenschaften in die nächste Planungsphase einfließen kann. Zum anderen sollten aber auch die einzelnen Prozesse innerhalb des DevOps- Zyklus betrachtet werden, um in den nächsten Zyklen eine stetige Verbesserung zu erreichen.

Zukünftig wird das Thema DevSecOps an Bedeutung gewinnen. DevSecOps erweitert DevOps um eine Möglichkeit, die IT-Security mit einer "Jeder ist für die Sicherheit verantwortlich"-Denkweise anzugehen. Dabei werden Sicherheitspraktiken in die DevOps-Pipeline einer Organisation eingebracht. Das Ziel ist es, das Thema Security in allen Phasen des Softwareentwicklungs-Workflows zu berücksichtigen.

• DevOps sollte in Projekten von Anfang an umgesetzt werden.
• Der Initialaufwand ist zwar höher aber das tägliche Arbeiten im Projekt und der gesamte Prozess werden danach wesentlich effektiver.
• Es empfiehlt sich, mit Templates zu arbeiten. Templates erleichtern die Automatisierung und sind in anderen Projekten wiederverwendbar.
• Es sollte ein DevOps Engineer als zentraler Ansprechpartner für Prozesse und Tooling in das Team integriert werden.
• Signifikante Reduzierung der Fehlerrate: Mithilfe der Automatisierung werden manuelle Fehler ausgeschlossen.
• Ein hoher Grad an Testautomatisierung ist ein Must-have

DevOps funktioniert nur mit einem effektiven Einsatz von Tools. Diese Tools automatisieren manuelle Aufgaben und unterstützen Teams bei der Verwaltung komplexer und großer Umgebungen. Wir bei M&M setzen dabei standardmäßig auf Microsoft Azure DevOps. Mithilfe von Azure DevOps können unsere Teams den kompletten DevOps-Prozess einheitlich und mit einem Tool umsetzen.

• Boards
  Azure Boards bietet gängige Tools zur agilen Softwareplanung, wie Kanban Boards, (Sprint-) Backlogs und Scrum Boards. Zusätzlich können mit Dashboards auf das Projekt zugeschnittene KPIs visualisiert werden, um einen Überblick zum Status vergangener oder dem aktuellen Sprint zu erhalten.
• Repos
  M&M verwendet standardmäßig GIT Repositories. Azure Repos erweitert das Versionskontrollsystem Git um nützliche Features, die den DevOps-Workflow verbessern und den Automatisierungsgrad erhöhen:
  - Pull Requests: Erlauben eine einfache Kollaboration zwischen mehreren Entwicklern und ermöglichen detaillierte Code-Reviews bevor neuer Code in die gemeinsame Codebasis gelangt.
  - Branch Policies: Gezielter Schutz von wichtigen Branches im Repository. Bspw. lassen sich dadurch die Änderungen eines Pull Requests durch Builds validieren, bevor sie in die gemeinsame Codebasis übernommen werden.
  - Build Trigger: Anstoßen von CI/CD bei Änderungen im Repository, um eine vollautomatische DevOps Pipeline zu realisieren.
• Pipelines
  Das Herzstück von DevOps. Mit Azure Pipelines sind keine Grenzen gesetzt, um jegliche Aktionen innerhalb eines Softwareprojekts zu automatisieren. Prinzipiell können hier alle Programmiersprachen oder Frameworks integriert und zu vielen verschiedenen Cloud-Providern deployed werden.
  Bisher waren Build- und Release-Pipelines getrennt. Neuerdings werden beide Schritte in einer Multi-Stage Pipeline zusammengefasst, mithilfe von YAML definiert und im Repository neben dem Sourcecode der Anwendung abgelegt, ganz im Sinne von DevOps.
• Test Plans
  Mit den Azure Test Plans wird eine Umgebung zum Planen, Ausführen und Nachverfolgen von explorativen und manuellen Tests geboten. Test Pläne werden in Test Suites gruppiert, die die einzelnen Test Cases beinhalten. Des Weiteren können verschiedene Systemkonfigurationen definiert werden, bspw. eine Unterteilung in verschiedene Betriebssysteme oder Browser. Beim Ausführen von manuellen Tests können direkt per Web-UI die Resultate der einzelnen Schritte mit Screenshot oder Videoaufzeichnung dokumentiert werden.
• Artifacts
  Azure Artifacts bietet ein vollständig verwaltetes Paketmanagementsystem mit nativer Unterstützung von NuGet, npm, Maven und Python Paketen. Hier lassen sich private und öffentliche Feeds in mehreren Ebenen (local, pre-release, release) erstellen, die vom Entwickler PC mit den Standardtools sowie in Azure Pipelines abgerufen werden können.