Vor ein paar Blog-Einträgen habe ich über die sanfte Wechsel eines Versionskontrollsystems geschrieben und mein Kollege Helge Biel hat detailliert über technische Aspekte, wie wir der Migration begegnet sind berichtet und dies historisch konkret eingeordnet.
Heute ist die Migration zur 100% fertig und auch die zwei nicht mehr benötigten svn-Server sind entsorgt und zur fachmännischen Verschrottung freigegeben. Äh Moment, da war doch was?!?
Nicht alles war von Anfang an so geplant…
Und schon komme ich zu einem wichtigen Punkt. Es war am Anfang nicht geplant alles von der svn-Infrastruktur zu entsorgen. Erst mit dem Umschwenken und der Erkenntniss bzw. Gewissheit, wir migrieren die gesammte Historie von unserem doch recht großen Repository und der Anforderung das Repo bleibt trotzdem handhabbar, war klar, dass wir die beiden Server durch einen git-Server ersetzen können.
Anfänglich war ein read-only Modus für die Kompletthistorie auf einem kleineren svn-Server vorgesehen. Entsprechend haben wir jetzt einen deutlich geringenen ökologischen Footprint und weniger Wartungsaufwände durch die Betreuung nur eines git-Servers. Auf der Entwicklungsseite haben wir den Vorteil, dass ausschließlich git-Skills bei den Mitarbeitern erforderlich sind. Die Verwendung eines Standard-VCS ist deutlich einfacher für alle.
Branching und Versionierung
Ein weiterer Punkt bei der Umstellung war die gewonnene Freiheit bei der Festlegung beim Branchen und der Versionierung. Hier haben wir einfach auf der grünen Wiese begonnen und frei arbeiten können. Die alten Wochenbuilds abzuschaffen und vieles darauf basierend zu automatisieren, vereinfachte das Vorgehen und das Vermitteln der Prozesse bei den Mitarbeitern erheblich. Die Menge an produktionsrelevanten Branches sinkt deutlich. Dadurch sind auch hier alt hergebrachte Prozesse weggefallen, auch wenn es bei einigen Kollegen schwer war zu vermitteln, dass es auch einfacher geht. Hier lag der Clou in der vorab ausgereiften Beispiellösung. Die machte vieles klarer und transparenter, erforderte weniger Abstraktion von zukünftigen Prozessen.
Versionierung gemäß Sprachgebrauch verhindert Missverständnisse und Fehler
Das Thema „Umstellung der Versionierung“ auf ein dem Sprachgebrauch im Konzern genügenden Ansatz hat viele Missverständnisse bei Fragen wie „wann kommt denn welches Feature bezogen auf Zeitpunkt und Version?“ aus der Vergangeheit beseitigt. Die Fehleranfälligkeit im Prozess der Featureentwicklung oder beim Bugfixing ist damit beseitigt und alle, egal ob Entwickler, Product-Owner, Testverantwortlicher oder Fachbereichsmitarbeiter oder andere Rolleninhaber sind zufrieden.
Trotzdem sind wir nicht eingeschränkt, so dass wir zum Beispiel die Anzahl an Releasezyklen einfach erhöhen könnten. Die gefundene Versionierung ist offen für weitere Verbesserungen und Beschleunigungen, passt genau zu dem Produktentwicklungsmodell.
Der Mensch
Verlassen wir die Prozesswelt und kommen zum menschlichen Aspekt der Migration, da hat der Mitarbeitende:
- ein aktuelles Versionskontrollsystem an die Hand bekommen, gemäß den aktuellen Standards von heute. Neue Kollegen kommen deutlich schneller in einen produktiven Modus und fühlen sich dadurch wohler,
- die erwartete Schulungsnotwendigkeit durch ergänzende externe Schulungen waren nicht notwendig, da wir bereits genügend Know-how im Hause hatten und wir zeitnah zur Migration täglich eine ‚Sprechstunde‘ als ViKo angeboten haben. Die Notwendigkeit der Unterstützung ebbte relativ schnell ab und mündet aktuell in eine „Community of practice“ (CoP),
- die CoP bietet allen Interessierten nun die Möglichkeit abweichende Workflows zu diskutieren und uns insgesammt als Entwicklungsorganisation weiter zu entwicklen, um bessere Ergebnisse zu generieren. Siehe zum Beispiel Umfragen zu der möglichen Nutzung von Pullrequests.
Umfragen im CoP für die zukünftige git-Nutzung
Kurzum die Reise geht ansich erst los und bietet nun mit dem neuen Versionskontrollsystem die Basis für Anpassungen.
Fazit
Am Ende ist der Code in einem gut zugänglichen aktuellen Versionskontrollsystem. Weitere Systeme aus der svn-Welt gibt es nicht mehr, die Dokumentation entspricht, bis auf das einfache aber doch individuelle Branchmodell der Firma, dem git-Standard und alte Prozesse und Mechanismen sind obsolet oder einfacher geworden.
Willkommen in der neuen Welt, mit weniger notwendigen Erklärungen bei neuen und alten Mitarbeitern. Standards werden genutzt so dass bestehendes Know-how direkt eingesetzt werden kann und neue Ansätze gemeinsam eingeführt und gelebt werden können, weil alte Prozesse dem nicht mehr im Wege stehen.
Persönlich muss ich sagen, dass mir die Umstellung eines VCS als nicht so wertig wie beispielsweise eine technologische Umstellung auf die Cloud oder ähnliches erschien. Da kommt eine Migration schnell in einen Verdrängungswettkampf mit anderen Anforderungen und fällt schnell hinten über.
Dies möchte ich an dieser Stelle revidieren. Es ist vielleicht schwieriger den monetären Mehrwert für einen Austausch des VCS zu bestimmen als die Vorteile zum Beispiel der Cloud zu beziffern, weil die positiven Auswirkungen sich erst später bemerkbar machen.
Aber die gewonnen Freiheitsgrade Prozesse zu vereinfachen und zu entschlacken und den Mitarbeitern ein aktuelles VCS anzubieten sind nicht zu unterschätzen. Daher möchte ich an dieser Stelle final eine Lanze brechen für alle, die das ansich schon angehen wollten, aber immer wieder verschoben haben. Es lohnt sich! – Selbst unter dem parallelen Druck der Host-Migration war dies bei uns möglich, also auch hier keine Ausrede mehr es nicht zu tun. In diesem Sinne: We love to move it!
Euer Frank Grzesiak-Mau
