Advanced Continuous Integration

AdvancedContinuous Integration

Ein Projektbericht

Wer sind wir?

[email protected]: attermr

GitHub: rattermeyer

[email protected]: stefanscheidtGitHub: stefanscheidt

© OPITZ CONSULTING GmbH 2011 Seite 3Mobile JavaScript-Web-Apps

MissionWir entwickeln gemeinsam mit allen Branchen Lösungen, die dazu führen, dass sich diese Organisationen besser entwickeln als ihr Wettbewerb.

Unsere Dienstleistung erfolgt partnerschaftlich und ist auf eine langjährige Zusammenarbeit angelegt.

LeistungsangebotBusiness IT AlignmentBusiness Information ManagementBusiness Process ManagementAnwendungsentwicklungSOA und System-Integration IT-Infrastruktur-Management

MärkteBranchenübergreifendÜber 600 Kunden

29%Industrie / Versorger /

Telekommunikation

29%Handel / Logistik / Dienstleistungen

42% Öffentliche Auftraggeber / Banken und Versicherungen / Vereine und Verbände

EckdatenGründung 1990 400 Mitarbeiter9 Standorte

Wer sind Sie?

Die Herausforderung

Also mussten wir uns beeilen ...

Aber manchmal waren wir zu schnell ...

Abhilfe durchContinuous Integration

Continuous Integration Process

1. […] wait for it to finish […] work with the rest of the teamto 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

Continuous Integration Process

1. […] wait for it to finish […] work with the rest of the teamto 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."

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!

Wie kann ein Prozess aussehen, bei dem ein

kaputter Build kein „stop-the-line“ bedeutet?

We want TeamCity‘s Feature back:

Pre-Tested Commits

Breaking the build is no crime!

Voraussetzung:Einfaches Branching und Merging

development

rat/for-development

mis/for-development

mho/for-development

Ein Branch pro Entwickler

Entwicklungsbranch, in den integriert werden soll: Branch pro Entwicklermit Namenskonvention

Entwicklerbranches werden von development abgespaltenEntwicklerbranches sind „privat“Entwicklerbranches werden vom CI-System wieder in development integriert

Variation: Feature Branches

Wichtige Punkte(nicht-offensichtlich)

Abgleich immer über den Integration-BranchSelbst wenn mehrere Entwickler

am gleichen Feature arbeiten

Kein direkter Merge eines Feature-Branchin den lokalen Working-Branch

Außer man weiß, was man tut ...

Vorteile

Ich kann unabhängig arbeitenund zentral sichern

Das CI-System führt die zeit- und resourcenaufwändigen Tests für mich durch

… während ich schon weiter arbeiten kann

Vorteile

Der Integration-Branch ist immer grünDurch einen Merge hole ich nur „guten“ Code

Ich kann ziemlich sicher sein, dass der Code auch nach dem Merge gebaut werden kann

Vorteile

Als Entwickler verbringe ich nichtunnötig Zeit damit Dinge zu fixen,die andere kaputt gemacht haben

Eine Umsetzung

+

Jenkins Git Plugin 1/3

Überwache Entwicklerbranches


Merge Entwickler-Branch auf Development-Branch


Push merged Development-Branch

zurück, wenn Build erfolgreich

Entwicklungsprozess aus Entwicklersicht

origin/development

git fetchgit merge orgin/development

git add / commit

git push origin rat/for-development

1. Merge2. Build3. Push

Demo ...

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-ZyklenHohe Latenz, bis Kollegen

von Änderungen profitieren können


Oder will ich sogar nochein echtes Code-Review?

Nicht allein durch Jenkins möglichZum Beispiel Gerrit als Review-Tool

Code-Reviews für jeden Commitbei jungen Projekt sehr aufwändig


Lesson Learned:

Die Kriterien ändern sich im Projektverlauf


Anfangs: Alle Tests müssen grün seinHäufig große Änderungen

Integrationstests hatten deutlich mehrAussagekraft als Unit Tests

Später: Unit-Tests müssen grün seinWeniger „breaking changes“

Integrationstestfehler mit 4h Zeitverzugentdecken reicht aus

Die Konsequenz ...

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:

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:

Dies und das ...

Durchsetzen der Konvention: Protected Branches

Beispiel: GitLab

Protected branches are designed to preventpush for all except masters. This ability allows:• keep stable branches secured• forced code review before merge to

protected branches

Pull statt fetch/merge[branch "rat/for-development"] remote = origin merge = refs/heads/rat/for-development

.git/config


[branch "rat/for-development"] remote = origin merge = refs/heads/development

.git/config

.git/config


[branch "rat/for-development"] remote = origin merge = refs/heads/development

$ git pull

From git-e.opitz-consulting.int:cel/oc-days-git-2013 d40fefe..86878f9 development -> origin/developmentAlready up-to-date.

.git/config

.git/config

Gotchas

Polling durch Jenkings undmehrere Commits in Zeitfenster

Besser:post-receive Hook

Web Hooks in Stash und GitLab

Gotchas

„Git hat meine Änderungen verschlampt“

==

„Ich habe nicht gemerkt, dass mein Commit nicht sauber gemerged werden konnte“

Noch Fragen?

Referenzen(Attribution Creative Commons)

Dokumentenhaufen:http://www.flickr.com/photos/katerha/5013886721/Crashed T14:http://www.flickr.com/photos/77326563@N06/8652444158/Question Mark:http://www.flickr.com/photos/colinkinner/2200500024/Tractor on the Road:http://en.wikipedia.org/wiki/File:Tractor-OnTheRoad01.jpgGeek & Poke:http://geek-and-poke.com/ http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef017743a87369970d-piJail:http://www.flickr.com/photos/schnaars/3036446157

http://www.flickr.com/photos/katerha/5013886721/



http://www.flickr.com/photos/77326563@N06/8652444158/



http://www.flickr.com/photos/colinkinner/2200500024/



http://en.wikipedia.org/wiki/File:Tractor-OnTheRoad01.jpg



http://geek-and-poke.com/



http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef017743a87369970d-pi

http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef017743a87369970d-pi

http://www.flickr.com/photos/schnaars/3036446157



Advanced Continuous Integration

Technology

Transcript of Advanced Continuous Integration