I Commited to Main

Hi,

Ich habe auf main committed. Einfach so 🫢

, du wirst wahrscheinlich eine von zwei Reaktionen haben:

“Ja und? Langweile mich nicht damit!”
oder

“WTF? DAS GEHT DOCH NICHT!”

Wenn du zu der Kategorie des ersten Beispiel gehörst: Cool! Entweder du bist noch nicht live und hast die Freiheit Trunk-based zu entwickeln, oder deine Organisation ist so weit mit der Automatisierung und dem DevOps Gedanken, dass du auch Trunk-based entwickeln kannst.

Alles ist cool! Hier gibt es nichts zu sehen. Wir sehen uns im nächsten Newsletter!

Aber… Wenn du zur zweiten Kategorie gehörst. Wenn sich deine Nackenhaare beim Lesen aufgestellt haben. Dann habe ich hier was für dich.

In meinem ersten Job waren wir 10 Backend Entwickler

Wir mussten unsere Arbeit synchronisieren. und natürlich gab es peer-reviews. Es war zu schmerzhaft, wenn der Trunk kaputt ist. Es hielt das ganze Team auf.

Deshalb gab es eine einfache, grundlegende Regel: Jeder Change muss gereviewed sein, bevor er in den Trunk kommt.

Easy.

1. Ticket in Progress nehmen
2. Trunk pullen
3. Branch erstellen
4. Code verändern
5. Branch pushen
6. Pull-Request aufmachen
7. auf Pipeline warten
8. Ticket in review setzen
9. Peer-Review abwarten
10. Feedback umsetzen
11. Peer Review abwarten
12. (repeat)
13. Mergen
14. Ticket auf Done schieben.

Easy.

Doof nur, wenn ich mal schnell einen Typo in der Dokumentation fixen möchte.

1. Trunk pullen
2. Branch erstellen
3. Typo fixen
4. Branch pushen
5. Pull-Request aufmachen
6. Ticket (im Nachhinein) erstellen
7. Ticket in Review setzen
8. Peer-Review abwarten
9. Mergen
10. Ticket auf Done schieben.

Und das nur für einen kleinen Typo?

Mäh.

Solche Änderungen habe ich dann einfach nicht gemacht. Oder zumindest nicht so kleinteiligt. Vielleicht habe ich sie einfach in einen vorhanden Branch aufgenommen.

Aber manchmal ist dieser Branch dann nie gemerged worden. Der Typo Fix also auch nicht. Aber egal 🤷‍♂️

Kommt dir der Workflow bekannt vor?

Es ist ja nicht so als hätte ich mir das erfunden. So habe ich lange gearbeitet. Und so habe ich zuletzt auch bei einem Kunden gearbeitet.

Die Folge ist aber, dass ich kleine, triviale Verbesserungen nicht mehr gemacht habe. Und das ist doch schade.

Kurz die Welt ein kleines Stück besser machen. Ohne dogmatischen Aufwand. Wäre doch gut, wenn das geht.

Mit Ship / Show / Ask gibt es ein Pattern, dass du heute übernehmen kannst

Das eigentliche Problem liegt darin, dass wir uns dogmatisch an die Regel “Alles muss gereviewt sein” halten.

Rouan Wilsenach hat 2021 in Martin Fowlers Blog einen Artikel mit dem Titel Ship / Show / Ask veröffentlicht .

Essenziell geht es um das gleiche Problem.

Sein Vorschlage ist total trivial. Lasst uns doch einfach von der Regel abweichen.

Gebt den Entwicklern wieder die Verantwortung selbst zu beurteilen, ob ihre Änderung ein Review braucht, oder nicht. Oder reichen nur die automatisierten Checks? Vielleicht. Der Entwickler sollte es wissen.

Und deswegen schlägt er drei Varianten vor:

Ship : Commit direkt in den Trunk. Um einen Typo zu fixen brauchen wir keinen Prozess.
Show : Merge direkt nach den automatisierten Tests, ohne approval. Wenn es Änderungswünsche gibt, dann wird halt ein neuer PR aufgemacht.
Ask: Kennen wir. Wir warten auf ein approval für unseren Change.

Das spannende an dieser Idee ist, dass der individuelle Entwickler beurteilt wie er es handhaben möchte. Für den einen ist es vielleicht zu riskant direkt auf den Trunk zu commiten. Da ist es vollkommen okay erst ein approval abzuwarten. Nichts hält den Entwickler dazu auf. Letztlich bleibt der individuelle Entwickler in der vollen Verantwortung. Wenn er einen Fehler macht, dann muss er daraus lernen.

Aber wir halten uns nicht mehr mit dogmatischen Prozessen für triviale Änderungen auf.

Eine gute Idee. Schlag das doch mal bei dir im Team vor!

Rule the Backend,

~ Marcus