Trunk-based Branching Modell – Fundament für DevOps Teams
Nach einigen durchwegs erfolgreichen Jahren der Produktentwicklung mit dem Git flow branching model scheint sich für erfolgreiche DevOps orientierte Teams das Trunk-based Development Branching Modell zu etablieren. Aus diesem Modell der Zusammenarbeit ergeben sich ein paar Konsequenzen:
- Um den Masterbranch immer „lauffähig“ zu haben, tendieren Entwickler dazu kleine Änderungen zu mergen. Kleine Änderungen bedeuten wenig Risiko.
- Feature Branches werden aufgrund kleiner Code Änderungen sehr kurzlebig, wodurch Entwickler äußerst selten in die unangenehme Situation mit Berge-Konflikten kommen. Dave Farley hat einen Rat dazu: „Don’t branch“
- Entwickler zerlegen ihre Arbeit in viele kleinere Bestandteile und „liefern“ viel öfter. Dadurch entstehen im Rahmen einer Feature Entwicklung viel mehr Punkte wo man theoretisch die Richtung noch anpassen kann.
- Entwickler tendieren dazu sich mehr Gedanken über Unit Tests und Testabdeckung zu machen.
- Entwickler neigen außerdem dazu die Commits mit besseren Commit-Messages zu versehen, was insgesamt zu einer besseren Dokumentation im Commit-Log führt.
Aus eigener Erfahrung wissen wir, dass es ein paar Wochen dauert, bis man den Sprung zum Trunk-based Branching Modell geschafft hat. Wenn man es aber einmal verinnerlicht hat, will man nicht mehr zurück.
Für Teams und Firmen die DevOps praktizieren wollen, sodass Code Änderungen oft, schnell, mit wenig Risiko, in guter Qualität und automatisiert produktiv gestellt werden können ist das Trunk-based Branching Modell eine fundamentale Basis in der täglichen Arbeit.