Ein Angebot von

DevOps – alles agil, oder was? Agile und klassische Prozesse im Vergleich

| Autor / Redakteur: Gerd Herbertz * / Stephan Augsten

Innovative Software-Produktionsstraße.
Innovative Software-Produktionsstraße. (Bild: adesso AG)

Bei dem ganzen Hype um DevOps und Agile vergisst man schnell, dass sich die klassische Softwareentwicklung manchmal besser eignet. Ein Vergleich zweier Software-Produktionsstraßen im Kontext klassisch versus innovativ zeigt die Grenzen der Agilität auf.

Immer wieder wird DevOps als technologisches Allheilmittel genannt, wenn es darum geht, Software schnell in die Produktion zu bringen. Mal abgesehen von den Anpassungen in der Organisation – flache Hierarchien als Matrix- oder Linienorganisation – und Prozeduren – Anfang-zu-Ende-Verantwortung für das Rollout eines Softwareprodukts bzw. Services –, ist die Technologie im Zusammenspiel mit der Software-Entwicklung die primäre Basis, damit dies überhaupt möglich ist.

Zwei Faktoren können hier als Schlüsselkriterien für Agilität genannt werden:

1. Zeitraum für die Bereitstellung einer IT-Umgebung für eine Neuanwendung: Entwicklung, Test, Referenz, Produktion.


2. Zeitraum zum Ausrollen einer Software-Änderung (Release-Zyklus) von der Entwicklung bis hin zur Produktion.

Der folgende Artikel beschreibt grundsätzlich die Unterschiede der klassischen und agilen Software-Entwicklung bis zur Übergabe in den Betrieb. Dazu wird eine ganzheitliche Sicht im Kontext einer Software-Produktionsstraße verwendet.

Die beiden Schlüsselkriterien – die Bereitstellung einer IT-Umgebung und das Ausrollen einer Software-Änderung – sind auf Basis von Erfahrungswerten entsprechend dargestellt, damit Gesamtlaufzeiten ermittelt werden können. Somit kann im direkten Vergleich der Unterschied erkannt und zugleich auch Limitierungen abgeleitet werden.

Die klassische Software-Produktionsstraße

Die Softwareentwicklung ist noch nach dem Wasserfall-Prinzip orientiert und die meisten Übergabe-, Build- und Testmechanismen sind manuell ausgeprägt. Es existiert eine organisatorische Trennung zwischen Dev (Development, Entwicklung) und Ops (Operations, Betrieb).

Wesentlicher Ablauf:

Klassische Software-Produktionsstraße.
Klassische Software-Produktionsstraße. (Bild: adesso AG)

  • 1. Code-Übergabe durch den Entwickler in das Repository.
  • 2. Build-Prozess (Kompilieren, Artefakt-Erstellung und ggf. erste Unittests).
  • 3. Bereitstellung der Entwicklungsumgebung durch Ops.
  • 4. Aufbau und Test der Entwicklungsumgebung durch den Entwickler.
  • 5. Funktionstest durch den Fachbereich: nach erfolgreichem Test ist die Entwicklungsumgebung einsatzfähig.
  • 6. Bereitstellung der Testumgebung durch Operations.
  • 7. Aufbau und Test der Testumgebung durch den Entwickler.
  • 8. Funktionstest und fachliche Abnahme durch den Fachbereich: nach Funktionstest und fachlicher Abnahme durch den Fachbereich ist die Testumgebung einsatzfähig.
  • 9. Releasemanagement-Prozess zum Aufbau der produktionsnahen Umgebungen.
  • 10. Bereitstellung der Referenzumgebung durch Ops und betriebliche Abnahme.
  • 11. Manuelle Funktionstest durch den Fachbereich: nach Funktionstest durch den Fachbereich ist die Referenzumgebung einsatzfähig.
  • 12. Bereitstellung der Produktionsumgebung durch Ops und betriebliche Abnahme.
  • 13. Manueller Funktionstest durch den Fachbereich: nach Funktionstest durch den Fachbereich ist die Produktionsumgebung einsatzfähig.

Die innovative Software-Produktionsstraße

Innovative Software-Produktionsstraße.
Innovative Software-Produktionsstraße. (Bild: adesso AG)

  • 1. Die Softwareentwicklung ist agil, DevOps-Technologie mit hohem Automationsgrad sind etabliert. Es existiert keine organisatorische Trennung zwischen Dev (Entwicklung) und Ops (Betrieb).
  • 2. Wesentlicher Ablauf:
  • 3. Code-Übergabe durch den Entwickler in das Repository.
  • 4. CI: Continuous-Integration-Prozess (Kompilieren, Unittest, Codequalitätsprüfung, Artefakt-Erstellung).
  • 5. Automatische Bereitstellung der Entwicklungs- und Testumgebung durch ein DevOps-Team mittels Infrastructure as Code (IaC).
  • 6. CD: Ausrollen der Anwendung auf die jeweilige Umgebung mittels Continuous Delivery.
  • 7. Automatisierte Integrationstests der Stages: die Entwicklungsumgebung wird ohne weitere Tests des Fachbereiches automatisch bereitgestellt.
  • 8. Manuelle Fachtests und fachliche Abnahme der Testumgebung durch den Fachbereich: nach Funktionstest und fachlicher Abnahme durch den Fachbereich ist die Testumgebung einsatzfähig.
  • 9. Releasemanagement-Prozess zum Aufbau der produktionsnahen Umgebungen (Referenz und Produktion): dieser Prozess ist erforderlich (analog zur klassischen Welt), um Abhängigkeiten zu anderen IT-Systemen zu prüfen.
  • 10. Automatische Bereitstellung der Referenz- und Produktionsumgebung durch ein DevOps-Team mittels IaC.
  • 11. CD: Ausrollen der Anwendung auf die jeweilige Umgebung mittels Continuous Delivery.
  • 12. Automatisierte Integrationstests der Stages.
  • 13. Manuelle Fachtests und fachliche Abnahme der Referenz- und Produktionsumgebung durch den Fachbereich: damit sind die produktionsnahen Umgebungen bereitgestellt.

Was bremst die Agilität?

Wenn man sich die obige Darstellung beider Welten anschaut, wird zuerst einmal verdeutlicht, welche Geschwindigkeitsunterschiede existieren – sofern in einer innovativen Software-Produktionsstraße im Gegensatz zur klassischen Welt weitgehend Automatismen wie CI, CD, IaC und Integrationstests verwendet werden. Was das für die Innovationskraft der IT bedeutet, muss nicht weiter erklärt werden.

Fachliche Freigaben

Was in der Praxis zumeist nicht automatisiert wird, sind die Freigaben der Fachbereiche für die jeweiligen Stages (Test, Referenz, Produktion). Bedingt durch Überlastung der Mitarbeiter und nicht optimalen Vertretungsregelungen können Fachfreigaben (sofern nicht mit entsprechendem Vorlauf geplant) mehrere Tage Verzögerung generieren (circa vier bis sieben Tage). Hierdurch wird die grundsätzliche Agilität der Infrastruktur gebremst, da die reine Bereitstellung (IaC, CD sowie Integrationstests) in wenigen Stunden (circa ein bis zwei Stunden) durchführbar ist.

Release-Management

Der Prozess, der anfänglich am meisten unterschätzt wird, ist der Release-Management-Prozess. Dieser stellt sicher, dass Softwareänderungen keine Auswirkungen auf Schnittstellen oder Dritt-Systeme innerhalb der IT-Landschaft haben. Genau hier liegt das Problem.

Sofern keine Abhängigkeiten existieren, kann quasi jederzeit ein Software-Release ausgerollt werden. Sobald aber Abhängigkeiten zu nicht-agilen IT-Systemen existieren (also zum Beispiel schwergewichtige Backends oder Hosts), definieren sich die Release-Zeiten an der Taktung dieser Systeme.

In der Praxis wird dies für ein Major/Minor-Release bis zu drei Monate dauern. Was das dann für den Agilitätsgedanken heißt, ist klar. Die Agilität folgt den klassischen Laufzeiten einer Software-Produktionsstraße, wenn Abhängigkeiten zu nicht-agilen IT-Systemen existieren.

Lösungsansätze

Automatisierung der fachlichen Freigaben: Um die höheren Laufzeiten der manuellen Freigaben durch die Fachbereiche zu beschleunigen, ist die Antwort recht einfach: „Automatisiere alles“. Das heißt, dass die in der Regel überschaubaren Testfälle der Fachbereiche automatisiert werden.

Einführung eines agilen Release-Typs im Release-Management: Das mit Abstand größte Problem ist die Einbindung beziehungsweise Berücksichtigung des Release-Managements im Kontext einer innovativen Software-Produktionsstraße. In der Regel existieren Release-Prozesse für Major, Minor-Releases und Hot-Fixes. Es gibt nun zwei Varianten, denen man grundsätzlich folgen kann:

1. Keine Integration in das Release-Management: Die Anwendungsarchitektur der jeweiligen Fachanwendung ist so definiert, dass keinerlei Abhängigkeiten zu anderen IT-Systemen existieren. Dann kann jederzeit ein Software-Release ausgerollt werden

Gerd Herbertz
Gerd Herbertz (Bild: adesso AG)

2. Integration in das Release-Management: Sofern Abhängigkeiten existieren, empfiehlt sich, einen weiteren Release-Typen „Agil“ zu definieren. Dieser Release-Typ wird inhaltlich zwischen Minor-Release und Hot-Fix positioniert. Das heißt, es wird vorab ein Abhängigkeitsgrad ermittelt und dann entschieden, wie schnell ausgerollt werden kann. Sofern der Release-Typ agil ist, wird dieser schneller ausgerollt als ein klassisches Minor-Release (circa vier bis sieben Tage angenommen).

* Gerd Herbertz, Jahrgang 1969, ist ausgebildeter Dipl. Ing (FH) Elektrotechnik. Bei adesso verantwortet er im Geschäftsfeld IT-Management Consulting das Competence Center Infrastruktur & Technologie, welches sich mit den Technologiestacks Microsoft und Linux beschäftigt. Speziell im Linux-Umfeld liegt der Fokus auf Konzeption, Aufbau und Übergabe von DevOps-Umgebungen im Rahmen von Kundenprojekten. Neben dem reinen Engineering und der Technologieberatung wird das Portfolio des Competence Centers durch IT-Management- und Strategieberatung abgerundet.

Hybrides Projektmanagement

Hybrides Projektmanagement

31.07.19 - Klassisches oder agiles Projektmanagement? Diese Frage hat sich in vielen Unternehmen zur Glaubensfrage entwickelt. Dabei haben beide Ansätze Stärken und Schwächen. Deshalb ist es in der Praxis oft sinnvoll, das Beste bzw. Zielführendste aus den beiden Projektmanagement-Welten zu vereinen. lesen

Die agile Geschwindigkeitslüge

Die agile Geschwindigkeitslüge

26.07.19 - „Mein Auftrag ist es, hier Geschwindigkeit reinzubringen!“ Mit diesen markigen Worten wird die Agile Transition in so manch einer Firma eingeläutet. Das häufige Ergebnis: Die Fluktuation beim Personal steigt – und die versprochenen Zuwächse an Produktivität bleiben aus. lesen

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46055689 / Agilität)