Noch vor einiger Zeit war der Aufwand für das Releasen unseres Kernprodukts so um-fangreich, dass wir es nicht geschafft haben mehr als eine Version pro Jahr zu veröffen-tlichen. Wir hatten mit Dingen zu kämpfen wie komplexen Abhängigkeiten, großen ma-nuellen Aufwänden und Silos innerhalb der Firma. Um diese Probleme zu lösen waren technische und nicht-technische Schritte erforderlich. Technische Schritte waren unter anderem der Einsatz von Docker, wodurch das Deployment vieler Komponenten vereinfachen werden konnten. Durch die Aufteilung des anfänglichen Monolithen in kleine Microservices haben wir Abhängigkeiten reduziert und durch die Automatisierung vieler Prozesse den manuellen Zeitaufwand minimiert. Zum Beispiel hat sich der Aufwand für das Testen der Releaseartefakte durch Automatisierung von 3 Wochen auf wenige Minuten reduziert. Nicht-technische Schritte waren beispielsweise das Aufbrechen von festgefahrenen Firmenstrukturen, das Hinterfragen und Aufarbeiten von langwierigen Veröffentlichungs- und Kommunikationsprozessen, die Förderung und das Leben des DevOps Gedankens in der Firma und das Aufbrechen von Abteilungs-Silos. Zum Beispiel wurde ein neues Team aus Entwicklern geschaffen und die Schreibtische im selben Raum wie die der Infrastruktur- und Hosting-Verantwortlichen platziert. Durch das bloße Zusammensitzen in einem Büroraum wurde ein hoher Grad an Zusammenarbeit und Wissenstransfer erreicht. Durch den Einsatz dieser und anderer Maßnahmen konnten Aufwände derart reduziert wurden, dass mittlerweile anstatt von einem Release pro Jahr mehrere Releases pro Monat möglich sind und wir gleichzeitig Aufwände eingespart haben, deren Zeitaufwand in der Summe der Arbeitszeit einer Vollzeitstelle entspricht. In dem Vortrag werden die wichtigsten Schritte und Maßnahmen dargelegt, die wir unternommen haben um eine derartige Verbesserung unserer Release Prozesse herbeizuführen.

1. Releases: Aus Jahren werden Minuten
Mehr Outcome mit weniger Einsatz
Jan Mortensen
Software Developer

2. Speaker
VORSTELLUNG
› Jan Mortensen
› Master in Informatik
› Seit ca. 4 Jahren bei Inxmail
› 2 Jahre Softwareentwicklung am Kernprodukt
› 2 Jahre im Team Release Train

3. Inxmail
DER PIONIER IM E-MAIL-MARKETING

4. Zahlen und Fakten
RUND UM INXMAIL
19
Jahre
Erfahrung
150
Motivierte
Mitarbeiter
2.000
Zufriedene Kunden
200
Internationale
Partner
Ausgezeichneter
Service
120% 100%
Persönlicher
Ansprechpartner
100%
Made in
Germany

5. Updateprozess
GRÜNDE FÜR SCHNELLE UPDATES
Verringerung der Lead Time
› Software soll möglichst schnell ausgeliefert werden und Gewinn erwirtschaften
Iterative Entwicklung
› Ist die Änderung die ich mache die, die der Kunde braucht?
› Schnelles Feedback
Einfachere Updates
› Es müssen weniger Änderungen auf einmal ausgerollt werden
Fehler werden schneller entdeckt und haben weniger Auswirkungen
› Ausmaß inkonsistente Daten ist viel geringer, wenn der Zeitraum kleiner ist

6. Vorgehensweise
STAND 2016
Release steht an
› Alle geraten in
Panik
Informationen
sammeln
› Wie baut man ein
Release?
Release wird gebaut
› Artefakte werden
von Hand getestet
2000 Applikationen in
2 Stunden updaten
› Zeitdruck
› Fehleranfällig

7. Architektur
INXMAIL PROFESSIONAL
› Legacy Applikation
› Monolitische Architektur
› Single Tenancy Anwendung
› Besteht aus Server-Applikation und Java Swing Client

8. Organisation
DAS TEAM RELEASE TRAIN
› Dediziertes Team um am Release Prozess zu arbeiten
› Wurde aus dem Daily Business herausgenommen
› Arbeitet an technischen Änderungen um
das Release Train Konzept umzusetzen

9. Problemkategorien
ÜBERSICHT
Organisatorisches
DeploymentTesting

10. Problemkategorien
ORGANISATORISCHES
Organisatorisches
DeploymentTesting

11. Organisatorisches
ÜBERBLICK
› Prozesse technisch abbilden
› Automatisieren
Informationen müssen
zusammengesucht werden
› Aufbrechen von Silos
› Dev-Ops
Wissen ist nicht verteilt, sondern
nur bei einer Person / einem
Team
› Alte Zöpfe abschneiden
Viele Betriebssysteme und
Datenbanken werden
unterstützt

12. Organisatorisches
INFORMATIONEN FESTHALTEN
› Prozess technisch abbilden
› Alle Informationen sofort im Prozess einpflegen, sobald man sie erhält
› So müssen keine Informationen aus Wiki-Dokuseiten oder
PDF-Dokumenten zusammengesucht werden,
sondern sind implizit vorhanden

13. Organisatorisches
AUFBRECHEN VON SILOS

14. Organisatorisches
ALTE ZÖPFE ABSCHNEIDEN
› Unterstützung für 3 von 4 Datenbanksystemen eingestellt
› Unterstützung von diversen Betriebssystemen eingestellt
› Vermehrte Nutzung von externen Services

15. Problemkategorien
TESTING
Organisatorisches
DeploymentTesting

16. Testing
ÜBERBLICK
› Automatisieren
› Alte Zöpfe abschneiden
Hoher manueller Aufwand
z.B. beim Testen
› Sichtbarkeit erhöhen
Fehlschlagende Tests sind nicht
sichtbar
› Docker
Unzuverlässige
Testumgebung

17. Testing
RELEASE PIPELINE
› Automatisierung einzelner
Aufgaben
› Bei einem Release mussten viele
unterschiedliche Builds mit vielen
Parametern angestoßen werden
› Das war zeitaufwendig und
fehleranfällig

18. Testing
RELEASE PIPELINE
Release
Build
Artefakt
Test
Updatefile Build
Updatefile
Test
Lizenz
Updatefile Build
Lizenz
Updatefile Test
› Einfaches Formular um Release Build anzustoßen
› Jeder Einzelschritt stößt den nächsten an
› Parameter werden automatisch ermittelt

19. Testing
TESTFEHLSCHLÄGE SICHTBAR MACHEN

20. Testing
TESTUMGEBUNG ZUVERLÄSSIGER MACHEN
› Wechsel von Vagrant zu Docker
› Einfache Wegwerf-Docker-Images unseres Kernproduktes zum Testen

21. 1123 1123
28 10
2
1
3
8
0
1
2
3
4
5
6
7
8
9
0
200
400
600
800
1.000
1.200
2015 2016 2017 2018
Arbeitsstunden pro Release Anzahl Releases
Testing
ARBEITSSTUNDEN FÜR TESTAUFWÄNDE PRO RELEASE
~ 7 Monate

22. Problemkategorien
DEPLOYMENT
Organisatorisches
DeploymentTesting

23. Deployment
ÜBERBLICK
› Automatisieren
› Slotstrategie
› Docker, Kubernetes
Fehleranfälliges Deployment
› Microservices
Viele Abhängigkeiten /
Begrenzte Downtimes

24. Deployment
AUTOMATISIERTE UPDATE-VORBEREITUNG: ALTER PROZESS
› Langer Wiki-Artikel für die Dokumentation
› Es waren viele Schritte notwendig
› Viele Bash-Befehle haben den Prozess
fehleranfällig gemacht

25. Deployment
AUTOMATISIERTE UPDATE-VORBEREITUNG : NEUER PROZESS
› Ein einziger Bash-Befehl
› Alles weitere wird automatisch ermittelt

26. Deployment
SLOTSTRATEGIE
› Server werden nach und nach geupdated
› Ein Bug betrifft nicht immer gleich alle Kunden

27. Deployment
MICROSERVICES
› Neue Funktionalitäten als Microservices
› Einzelne Services können unabhängig
vom Kernprodukt aktualisiert werden
› Zero Downtime für den Enduser

28. Deployment
DOCKER
› Hauptsächlich für Microservices
› Externe Einflüsse werden minimiert
› Deployment mit Docker ist einfacher handhabbar und schneller

29. Deployment
KUBERENETES
› Ressourcen können besser genutzt werden
› Einzelne Services können redundant deployed werden
› Zero Downtime Deployments

30. Vorgehensweise
STAND 2018
Release steht an
› Ruhig dasitzen und
lächeln
Release wird gebaut
› 2 Parameter
eintragen und
warten
Update vorbereiten
› Bashzeile kopieren
und Enter drücken
Update durchführen
› Scripte starten und
Kaffee trinken

31. Zusammenfassung
RELEASES: AUS JAHREN WERDEN MINUTEN
Automatisierung
Informationsverteilung
Man muss nicht immer jeden Kunden bedienen
Richtige Auswahl der richtigen Technologie für eine Problemlösung
Automatisierung

32. Vielen Dank für Ihre
Aufmerksamkeit