Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Pull Request ist ein Vorschlag, eine Reihe von Codeänderungen in einen geteilten Branch zu mergen. Der Autor hat die Arbeit in seinem eigenen Branch erledigt und bittet das Team nun, sie zu prüfen und zu übernehmen. Der Name stammt aus Git, und das Konzept trägt, wie die meisten Softwareteams auf GitHub, GitLab und Bitbucket zusammenarbeiten.
Eine Pull Request bündelt das Diff, eine Beschreibung, warum die Änderung existiert, und einen Thread, in dem Reviewer Kommentare hinterlassen. Automatische Prüfungen hängen sich daran: die Testsuite läuft, Linter melden Stilprobleme, und die Deployment-Pipeline kann die Änderung vor dem Merge in der Vorschau zeigen. Reviewer geben frei, fordern Änderungen oder stellen Fragen, und die Request wird gemergt, sobald sie durch ist. Ein Entwickler, der einen Checkout-Bug behebt, öffnet eine Pull Request, die Tests laufen von selbst, ein Kollege sieht, dass die Korrektur eine Währung übersieht, der Entwickler pusht eine Korrektur in dieselbe Request, und erst dann wird gemergt. Nichts erreichte den Hauptbranch, bevor es wirklich richtig war.
Die Disziplin liegt darin, Requests klein zu halten. Eine fokussierte Änderung ist leicht zu prüfen und sicher zurückzurollen. Eine riesige ist beides nicht, weshalb große Pull Requests gern die Bugs verstecken, die niemand die Energie hatte zu suchen.
Jede Änderung, die wir machen, läuft durch eine Pull Request. Sie ist die Arbeitseinheit, die wir prüfen, testen und ausliefern. Jede klein und in sich geschlossen zu halten, ist Gewohnheit, denn eine Pull Request, die Sie in einem Sitzen verstehen, ist eine, der Sie trauen können.
Unsere Pull Requests laufen durch CI/CD-Pipelines, die die Änderung testen und validieren, bevor ein Mensch sie überhaupt ansieht, sodass die Prüfzeit dem Urteil gilt und nicht der Mechanik. Arbeiten wir im Repository eines Kunden, folgen wir seinen Konventionen und heben die Latte, wo es hilft, nie durch Belehrung, nur durch klare Requests, die leicht zu prüfen und leicht zu mergen sind. Das Ergebnis ist ein stetiger Fluss kleiner, sicherer Änderungen statt nervenaufreibender Big-Bang-Releases.
Wollen Sie einen Workflow, in dem Ausliefern ruhig und umkehrbar ist? Richten wir ihn ein.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















