Scrum sieht vor, dass am Ende eines Sprints ein auslieferbares Inkrement als Ergebnis geliefert wird. Dieses Inkrement kann auch mal etwas grösser sein und hat bei uns immer wieder zu Problemen bei der Auslieferung geführt. DevOps strebt einen One-Piece-Flow an, also die direkte Auslieferung jeder einzelnen Änderung. Wir haben dies übernommen und einiges dabei gelernt.
In meinem Produktentwicklungsteam arbeiten wir nun seit etwas mehr als einem Jahr nach Scrum. Am Ende jedes Sprints haben wir ein Zeitfenster für die Auslieferung aller Änderungen der letzten zwei Wochen auf die Produktionsumgebung eingeplant. Im besten Fall laufen diese Deployments in weniger als einer Stunde reibungslos durch. Oftmals brauchen wir aber trotzdem zwei oder mehr Stunden dafür, da meist ein oder zwei Änderungen Probleme machen. Diese Änderungen blockieren dann aber die ganze Auslieferung. Der Stress steigt dabei im ganzen Team an, was absolut unnötig ist.
In mehreren Retrospektiven haben wir dieses Problem diskutiert und nach Lösungen gesucht. Wir wussten, je mehr Änderungen wir in einem Sprint machen, desto höher ist das Risiko, dass etwas nicht funktioniert. Und je mehr nicht funktioniert, desto länger ist der Unterbruch. Dadurch entfernen wir uns von unserem Ziel einer möglichst unterbrechungsfreien Auslieferung.
Eine mögliche Lösung dafür fanden wir im von DevOps angestrebten One-Piece-Flow für Änderungen. Das heisst, jede einzelne Änderung wird umgesetzt, getestet und schnellstmöglich einzeln ausgeliefert. Das Risiko ist dadurch minimal, da nur eine Änderung ausgeliefert wird und somit nur diese fehlschlagen kann. Ein möglicher Unterbruch wird ebenfalls minimiert. Soweit die Theorie.
Damit wir dies so umsetzen konnten, mussten aber diverse Voraussetzungen erfüllt sein. Eine die uns grosse Schwierigkeiten bereitet hatte, waren die Abhängigkeiten. Jede Änderung muss so gut es geht unabhängig von allen anderen Änderungen sein, sonst kann diese nicht einzeln ausgeliefert werden. Wir hatten vor allem zu Beginn grosse Schwierigkeiten damit, die voneinander abhängigen Änderungen an der Datenbank, an den Services und diejenigen der Clients auszuliefern.
Nach einigen Sprints hatte sich aber die Arbeitsweise verändert und jeder Entwickler berücksichtigte diese Art der Auslieferung bei seinen Änderungen. Hatten wir früher einen Release-Verantwortlichen pro Sprint, ist nun jeder Entwickler selbst dafür verantwortlich, dass seine Änderung getestet und fehlerfrei ausgeliefert wird.
Am Ende eines Sprints sind nun meist nur noch wenige Änderungen übrig, welche nicht einzeln ausgeliefert werden können oder einen spezielleren Prozess durchlaufen, wie z.B. die Auslieferung von Apps in den App Store oder Play Store.
Der Flow der Änderungen von der Entwicklung zum Kunden konnte somit optimiert werden. Erste Änderungen sind somit manchmal schon am ersten Tag des Sprints in der Produktion. Nie zuvor kamen unsere Kunden schneller zu den Änderungen und oftmals merken sie dies nicht einmal, wenn z.B. Bugfixes unterbrechungsfrei ausgeliefert werden.
Wir sind aber noch lange nicht fertig mit dieser Prozessoptimierung. Es fehlt uns noch eine automatisierte Feedback-Schleife, mit welcher wir schnell und zuverlässig feststellen können, ob unsere Auslieferungen Probleme machen oder ob sie gut funktionieren. Die Themen Monitoring, Testautomatisierung und Rollback-Fähigkeit stehen nun weit oben auf unserer To-Do-Liste.
