http://www.opitz-consulting.com/go/3-4-894
Die Literatur sagt, dass „Broken Builds“ auf jeden Fall zu vermeiden sind, weil andere Entwickler sich durch die fehlerhaften Änderungen ihren Entwicklungsbereich kaputt machen und dann nicht arbeiten können.
Die Solution Architects unserer IT-Beratung, Stefan Scheidt und Richard Attermeyer, zeigten in ihrem Vortrag am 10.Oktober 2013 bei der gearconf 2013 in Düsseldorf, dass „broken Builds“ nicht das Problem sind. Im Rahmen der Präsentation zeigten die Referenten, wie man durch geeignete Branching- und CI-Strategien stets eine stabilen Branch sicherstellen kann.
Veranschaulicht wurde das Ganze durch eine konkrete Umsetzung mittels Git / GitLab und Jenkins.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
9. Continuous Integration Process
1. […] wait for it to finish […] work with the rest of the team
to make it green before you check in
2. …
3. Run the build script and tests on your development
machine […]
4. […]
5. Wait for your CI tool to run the build with your changes
6. […]
7. If the build passes, rejoice and move on to your next task
Jez Humble, David Farley, Continuous Delivery
10. Continuous Integration Process
1. […] wait for it to finish […] work with the rest of the team
to make it green before you check in
2. …
3. Run the build script and tests on your development
machine […]
4. […]
5. Wait for your CI tool to run the build with your changes
6. […]
7. If the build passes, rejoice and move on to your next task
Jez Humble, David Farley, Continuous Delivery
11. Continuous Integration Process
1. […] wait for it to finish […] work with the rest of the team
to make it green before you check in
2. …
3. Run the build script and tests on your development
machine […]
4. […]
5. Wait for your CI tool to run the build with your changes
6. […]
7. If the build passes, rejoice and move on to your next task
Jez Humble, David Farley, Continuous Delivery
12. Continuous Integration Process
1. […] wait for it to finish […] work with the rest of the team
to make it green before you check in
2. …
3. Run the build script and tests on your development
machine […]
4. […]
5. Wait for your CI tool to run the build with your changes
6. […]
7. If the build passes, rejoice and move on to your next task
Jez Humble, David Farley, Continuous Delivery
13. Continuous Integration Process
1. […] wait for it to finish […] work with the rest of the team
to make it green before you check in
2. …
3. Run the build script and tests on your development
machine […]
4. […]
5. Wait for your CI tool to run the build with your changes
6. […]
7. If the build passes, rejoice and move on to your next task
Jez Humble, David Farley, Continuous Delivery
14. Continuous Integration Process
1. […] wait for it to finish […] work with the rest of the team
to make it green before you check in
2. …
3. Run the build script and tests on your development
machine […]
4. […]
5. Wait for your CI tool to run the build with your changes
6. […]
7. If the build passes, rejoice and move on to your next task
Jez Humble, David Farley, Continuous Delivery
"If everybody on the team follows these simple
steps every time they commit any change, you
will know that your software works on any box
with the same configuration as the CI box at all
times."
15. CI System soll für
mich arbeiten
- nicht umgekehrt!
WTF!
Etwas stimmt nicht!
Keiner bezahlt mich dafür
zu warten, um sicher zu
gehen, dass alle Tests
immer noch grün sind.
Ich will einchecken
wann ich will!
Ich will den meinen
Build kaputt gehen
lassen, wann ich will!
16. Wie kann ein Prozess
aussehen, bei dem ein
kaputter Build kein „stop-
the-line“ bedeutet?
20. development
rat/for-development
mis/for-development
mho/for-development
Ein Branch pro Entwickler
Entwicklungsbranch, in den integriert werden soll: Branch pro Entwickler
mit Namenskonvention
Entwicklerbranches werden von development abgespalten
Entwicklerbranches sind „privat“
Entwicklerbranches werden vom CI-System wieder in development integriert
22. Wichtige Punkte
(nicht-offensichtlich)
Abgleich immer über den Integration-Branch
Selbst wenn mehrere Entwickler
am gleichen Feature arbeiten
Kein direkter Merge eines Feature-Branch
in den lokalen Working-Branch
Außer man weiß, was man tut ...
23. Vorteile
Ich kann unabhängig arbeiten
und zentral sichern
Das CI-System führt die zeit- und
resourcenaufwändigen Tests für mich durch
… während ich schon weiter arbeiten kann
24. Vorteile
Der Integration-Branch ist immer grün
Durch einen Merge hole ich nur „guten“ Code
Ich kann ziemlich sicher sein, dass der Code
auch nach dem Merge gebaut werden kann
32. Kriterien für „Gut-Genug“
Müssen nur die „echten“ Unit Tests laufen?
Oder müssen alle Tests laufen?
(Unit-, Integrations- und Systemtests)
Lange Feedback-Zyklen
Hohe Latenz, bis Kollegen
von Änderungen profitieren können
33. Kriterien für „Gut-Genug“
Oder will ich sogar noch
ein echtes Code-Review?
Nicht allein durch Jenkins möglich
Zum Beispiel Gerrit als Review-Tool
Code-Reviews für jeden Commit
bei jungen Projekt sehr aufwändig
35. Kriterien für „Gut-Genug“
Anfangs: Alle Tests müssen grün sein
Häufig große Änderungen
Integrationstests hatten deutlich mehr
Aussagekraft als Unit Tests
Später: Unit-Tests müssen grün sein
Weniger „breaking changes“
Integrationstestfehler mit 4h Zeitverzug
entdecken reicht aus
37. Umkehr der Verantwortung
An: Meine Kollegen
Hallo,
habe meinen Code eingechecked, bin dann mal in Urlaub.
BTW: CI Server ist jetzt rot und meldet 15 Testfehler. Müsste sich
jemand mal anschauen…
Bis in 2 Wochen
früher:
38. Umkehr der Verantwortung
An: Meine Kollegen
Hallo,
wollte euch meinen Code noch vor dem Urlaub zu Verfügung
stellen. Hat mich leider noch 2 Stunden gekostet, die 15
Testfehler zu beseitigen. Jenkins hat den Code jetzt aber
erfolgreich gemerged. Alles grün!
Bis in 2 Wochen.
jetzt:
41. Beispiel: GitLab
Protected branches are designed to prevent
push for all except masters. This ability allows:
• keep stable branches secured
• forced code review before merge to
protected branches