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