I Commited to Main
Find the English version below
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.
- Ticket in Progress nehmen
- Trunk pullen
- Branch erstellen
- Code verändern
- Branch pushen
- Pull-Request aufmachen
- auf Pipeline warten
- Ticket in review setzen
- Peer-Review abwarten
- Feedback umsetzen
- Peer Review abwarten
- (repeat)
- Mergen
- Ticket auf Done schieben.
Easy.
Doof nur, wenn ich mal schnell einen Typo in der Dokumentation fixen möchte.
- Trunk pullen
- Branch erstellen
- Typo fixen
- Branch pushen
- Pull-Request aufmachen
- Ticket (im Nachhinein) erstellen
- Ticket in Review setzen
- Peer-Review abwarten
- Mergen
- 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
Hi ,
I committed to main
.
Just like that 🫢
, you're likely to have one of two reactions:
"So what? Don't bore me with that!"
or
"WTF? YOU CAN'T DO THAT!"
If you belong to the first category: Cool! Either you're not live yet and have the freedom to develop trunk-based, or your organization is so advanced with automation and the DevOps mindset that you can develop trunk-based too.
Everything's cool! Nothing to see here. See you in the next newsletter!
But... if you're in the second category. If your neck hairs stood up while reading. Then I have something for you.
In my first job, we were 10 backend developers
We had to synchronize our work. and of course, there were peer reviews. It was too painful when the trunk is broken. It held up the whole team.
So, there was a simple, fundamental rule: Every change must be reviewed before it goes into the trunk.
Easy.
- Take ticket in progress
- Pull trunk
- Create branch
- Change code
- Push branch
- Open pull request
- Wait for pipeline
- Set ticket in review
- Wait for peer review
- Implement feedback
- Wait for peer review
- (repeat)
- Merge
- Move ticket to done.
Easy.
It's just stupid if I want to quickly fix a typo in the documentation.
- Pull trunk
- Create branch
- Fix typo
- Push branch
- Open pull request
- (Posthumously) create ticket
- Set ticket in review
- Wait for peer review
- Merge
- Move ticket to done.
And all that just for a small typo?
Meh.
I simply didn't make such changes. Or at least not that detailed. Maybe I just included them in an existing branch.
But sometimes this branch was never merged. So the typo fix wasn't either. But whatever 🤷♂️
Does this workflow sound familiar?
It's not like I made this up. That's how I worked for a long time. And that's how I recently worked with a client.
The result, however, is that I stopped making small, trivial improvements. And that's a pity.
Just making the world a little bit better. Without dogmatic effort. Would be nice if that's possible.
With Ship / Show / Ask there's a pattern you can adopt today
The actual problem lies in the dogmatic adherence to the rule "Everything must be reviewed".
Rouan Wilsenach published an article titled Ship / Show / Ask on Martin Fowler's blog in 2021.
Essentially, it's about the same problem.
His suggestion is totally trivial. Let's just deviate from the rule.
Give developers back the responsibility to judge whether their change needs a review or not. Or are the automated checks enough? Maybe. The developer should know.
And that's why he proposes three variants:
Ship: Commit directly to the trunk. To fix a typo we don't need a process.
Show: Merge right after automated tests, without approval. If there are change requests, then just open a new PR.
Ask: As we know it. We wait for approval for our change.
The interesting thing about this idea is that the individual developer assesses how they want to handle it. For one, it might be too risky to commit directly to the trunk. Then it's completely okay to wait for approval first. Nothing stops the developer from doing so. Ultimately, the individual developer remains fully responsible. If they make a mistake, they must learn from it.
But we no longer bog ourselves down with dogmatic processes for trivial changes.
A good idea. Why not suggest it to your team!
Rule the Backend,
~ Marcus