Advanced Continuous Integration

Post on 13-Jan-2015

1,373 views 0 download

description

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

transcript

AdvancedContinuous Integration

Ein Projektbericht

Wer sind wir?

Richard.Attermeyer@opitz-consulting.comTwitter: attermr

GitHub: rattermeyer

Stefan.Scheidt@opitz-consulting.comTwitter: 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

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

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

Jenkins Git Plugin 2/3

Merge Entwickler-Branch auf Development-Branch

Jenkins Git Plugin 3/3

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

Kriterien für „Gut-Genug“

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

Kriterien für „Gut-Genug“

Lesson Learned:

Die Kriterien ändern sich im Projektverlauf

Kriterien für „Gut-Genug“

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

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

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

.git/config

.git/config

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

[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?