CruiseControl. Produktivitätsoffensive durch kontinuierliche Integration: CruiseControl im täglichen Einsatz. Peter Roßbach, Michael Kloss

Transkript

1 CruiseControl Produktivitätsoffensive durch kontinuierliche Integration: CruiseControl im täglichen Einsatz

2 Über uns... Michael Kloss Architekt, Coach itemis Gmbh & Co. KG Peter Roßbach Architekt, Coach, Apache Tomcat Committer Freiberufler 2

3 Agenda Ein paar Gedanken vorab... Kurze Einführung in Continuous Integration (CI) Vorstellung des CI-Frameworks Cruisecontrol Rollenverständnis schaffen Qualitäts- und Produktivitätsoffensiven ermöglichen Lessons Learned 3

4 Ein paar Gedanken vorab... Was kostet fehlende Qualität eigentlich wirklich? Warum wird an der Qualität gespart? Status Quo der Ausbildung? Wer macht was, mit welchen Voraussetzungen? Welche Rolle spielt wer, mit welcher Qualität? Entscheidet man sich für einen Prozess der auf Qualität achtet muss an ihn glauben ihn konsequent unterstützen alles daran setzen, diesen Weg zu gehen. Soziale Faktoren im Team Teammitglieder motivieren und darauf vorbereiten Nicht jeder Entwickler will in sein tiefsten Inneren in einem solchem Prozess mitmachen. Allerdings ist keiner gezwungen mit jedem zu Arbeiten. 4

5 Ein paar Gedanken vorab... Einführung ist ein Lernprozess alle lernen in dem Projekt es werden Situationen kommen, die kosten ${var} var := Geld Ressourcen Zeit Nerven Teams müssen konsequent ausgebildet werden In kleinen Projekten starten Fehler korrigieren und dann den Mut zum Durchstarten besitzen. 5

6 Kurze Einführung in Continuous Integration Was ist das? Definitionen Cruisecontrol als CI-Framework

7 Was soll das eigentlich? Jederzeit die Kontrolle über die Ergebnisse behalten. Eine Automatisierung der Herstellung unsere Anwendungen und Infrastruktur erreichen. Alle Ergebnisse der Herstellung sollen protokolliert und Neuigkeiten mitgeteilt werden. Eine aktive Fehlererkennung durch automatische Integration von automatischen Tests soll erfolgen. Einen Agilen Prozess als Grundlage eine qualitätsgesicherte Software von Anfang an zu gestalten. => Das beste Beispiel ist WebTest

8 Begriff der Build Verification Was bedeutet Build-Verifikation? Build = Bauen, Herstellen, Zusammensetzen Verifikation = Überprüfung Testen ( Unit-, Module-, Integrations- oder Lasttest) Protokollieren, Analysieren & Reagieren Continuous Integration Von Martin Fowler und Matthew Foemmel 2000/ Aktive Qualitätssicherung des Entwicklungsergebnis Permanente Fähigkeit ein Release zu haben

9 Continuous Integration kontinuierliche Integrationszyklen Ziele Freigabe der Software erfolgt regelmäßig oder wie oft geben Sie Ihre Ergebnisse bekannt? Kontrolle der Build und Testaktivität Wer kontrolliert es bei Ihnen und wenn, wie oft? Schnelles Feedback der Freigabe des Stands durch Kontrolle des Source Repositories, oder haben Sie keines? Schnelle Rückmeldung Fehler => Status => Änderungen => Status => Erfolg =>... Unterstützt verteilte und unabhängige Entwicklung Mehrstufige Kontrollinstrumente mit einheitlicher Technik schaffen

10 Umgebungen 10

11 Funktion des CruiseControl-Systems 11

18 Funktion des CruiseControl-Systems? 11

22 Protokoll Server 12

23 Rahmenbedingungen Prozesse Agile Entwicklung Soziale Faktoren Planung

24 Rahmenbedingungen Prozesse Kurze Zyklen - Continuous Integration Automatisierte Build-Prozesse Testgetriebene Entwicklung Organisation sowohl des Einzelnen als auch des Teams Time-Boxing aktives Reporting Transparenz im Team Gegenseitiges Review der Ergebnisse regelmässiges Review mit externen Partner 14

25 Rahmenbedingungen 15

26 Rahmenbedingungen Start 15

27 Rahmenbedingungen Start? 15

28 Rahmenbedingungen Start? Ergebnis 15

29 Rahmenbedingungen Start Ergebnis 15

30 Rahmenbedingungen? Integration Start Go Ergebnis 15

31 Rahmenbedingungen? Integration Start Go Ergebnis 15

32 Rahmenbedingungen Agiles Manifest Flexibel Coding Testing Listening Designing Offen für Veränderungen Basis- und Architekturänderungen kontrolliert durchführen Tests zur Kontrolle Anpassungsfähig 16

33 Rahmenbedingungen Soziale Komponente Unterstützung aller Entwickler und Manager Sicherheit schaffen Klarheit schaffen Keine Kontroll-Komponente etablieren niemand wird gerne kontrolliert aber Kommunikation & Feedback ist notwendig Abstumpfung vermeiden => Build Successful wichtig Motto: "Don't blame your colleague, support him!" 17

34 Rahmenbedingungen Planung Zeit aktiv planen Feedback produzieren Reports Check-Ins s Tests Feedback!= Kontrolle Reviews schaffen Checkstyle, JDepend, PMD sind letztendlich Review-Elemente manuelle Reviews 18

35 Der Weg nach oben... Vorlagen für Projekte/Module Rollen ausprägen Keine inflexiblen Konventionen

36 Lektion: Klein anfangen zahlt sich aus Aufgabe Ein kleines Team soll testgetrieben Vorgehen Probleme trotz Test-Cases geht zu viel in der Entwicklung schief nicht eingechecken oder unreflektiertes Einchecken bescheren Probleme Tests werden nicht oder immer mit gepflegt Schnittstellen-Konflikte treten trotzdem auf mögliche Lösung Tests häufiger ausführen Builds automatisiert ausführen mögliche Auswirkungen Team ignoriert diese Problematik Team reagiert auf die Testergebnisse 20

37 Lektion: Klein anfangen zahlt sich aus Zielgruppe ist in erster Linie das Team jeder muss den Successful Build wollen jeder muss sich dazu committen Konventionen schaffen für Checkins Einchecken ist immer ok Jeder muss den Build nach seinem Commit kontrollieren Build Failures müssen direkt behoben werden Alternative: Clean Baseline 21

38 Lektion: Klein anfangen zahlt sich aus Tests sind Code Tests sind genauso pflegsam zu behandeln wie Code Tests müssen an neue Anforderungen angepasst werden Basis schaffen, Tests auch häufig ausführen zu können Übergreifende Tests für Schnittstellen-Problematik einführen 22

39 Lektion: Feedback ausweiten Aufgabe erweitertes Reporting einführen Probleme Identifizierung welche Reports wirklich interessieren Welche Informationen helfen bei der Produktivitätssteigerung? Lösung Tailoring der möglichen Reports Auswirkungen Mehr Auswertungsaufwand => jemand muss die Ergebnisse interpretieren Team muss auf diese Ergebnisse reagieren 23

40 Lektion: Feedback ausweiten Setzen Sie weitere Feedback-Werkzeuge ein Checkstyle PMD / FindBugs CodePro Analytix XRadar Identifizieren Sie wichtige Reports für Ihr Projekt Fangen Sie an, empirische Daten über die Zeit zu betrachten Coverage Broken Builds Code Complexity etc. 24

41 Lektion: Feedback ausweiten Feedback ist sowohl wichtig für Entwickler Teamleiter Manager Automatisiertes Feedback erleichtert spontane Aussagen über den Zustand des Projekts 25

42 Lektion: Management verschiedener Teile Aufgabe Modularisierung des Projekts Probleme Vereinheitlichung des Build-Prozesses Pflege-Aufwand erhöht sich für das CI-System Lösung Konventionen schaffen Auswirkungen Granularität der Tests ändert sich einzelne Module testen Abhängigkeiten testen gesamtes Projekt testen Detailliertere & schnellere Informationen über den Zustand 26

43 Lektion: Management verschiedener Teile Lösung Vereinheitlichen der Projektstrukturen Konventionen für Build-Skripte Build-Systeme homogenisieren Module identifizieren Module wie eigenständige Projekte behandeln Module sind APIs und müssen nach aussen geschützt werden Release-Module Zuständig für Erstellung von Releases Übergreifende Tests Integrationstests 27

44 Lektion: Management verschiedener Teile Beispiel CC-Struktur Ant-Skripte masterbuild checkout all Projekte / Module gleiche Build-Verzeichnisse, z.b. "build", "build/classes", "build/dist" Erzeugnisse in gleiche Verzeichnisse Reports in gleiche Verzeichnisse 28

45 Lektion: Ausweiten der Automatisierung Aufgabe Last-Tests automatisieren Integrationstests Probleme Umgebung existiert für solche Szenarien nicht Einige Tests machen richtig Arbeit und dauern... Es müssen vollständige Testumgebungen aufgebaut werden. Lösung Die Organisation muss handeln! Auswirkungen Sie erhalten echte Informationen über das Verhalten der Anwendung unter nahezu produktiv-bedingungen 29

46 Lektion: Ausweiten der Automatisierung Zeitpunkt für Ausweitung der Automatisierung Software ist modularisiert. Jede Komponente ist getestet und besitzt einen eigenständiges Testsystem. Mehrere verschiedene Gruppen tragen zum Erfolg der Software bei. Es existieren Team die an unabhängigen Teilprojekten arbeiten. Es sollen weitere Qualitätstest benötigt. Lasttest von Teilmodulen Qualitätsmessung der Software Abhängigkeit der Module Testabdeckung QS-Reporting 30

47 Lektion: Ausweiten der Automatisierung Lösung: Gründung eines Buildmanagement Teams Beratung der Projekte Betreuung der Infrastruktur Sammeln und Weitergabe von Konventionen Werkzeugberatung Eigenes Budget und feste Kostenstelle im Projekt! Aufgaben: Minimierung der Rüstzeiten für Buildmanagement Aufbau einer verlässlichen Infrastruktur für Builds, Tests, Reporting und Dokumentation Flexibler Umgang mit neuen Herausforderungen und Werkzeugen. Die Teams sind der externe Auftraggeber und müssen auch so behandelt werden. 31

48 Lektion: Ausweiten der Automatisierung Beispiel: Mehrstufiger Buildprozess Abhängigkeiten der Module und Buildaufgaben verwalten Verschiedene Systeme für Entwickler-Feedback und Qualitätsreporting Integrations- und Lasttest und Reporting wir verlagert. QS-Daten werden historisch ausgewertet Veränderung der Testabdeckung Veränderung von Optimierung -> Beispiel Eclipse 3.1 Beispiel: Einige Buildaufgaben brauchen enormen Rechenpower! Software und Hardware Installation werden ein ernsthaftes Thema Automatisierung der Deployment und Auswertungen Beispiel: Reportingserver Zentrale Beauskunftung Integration von Projektspezifischen Ergebnissen 32

49 Kontrolle der Aktivtäten 33

50 Lektion: Grenzen überschreiten Aufgabe Grenzen des Buildmanagements ausweiten Zulieferer einbinden Probleme Alle Projekte müssen sich anpassen Zulieferer müssen sich anpassen Lösung Unternehmensrichtlinien festlegen Organisatorische Strukturen schaffen, die CI erlauben Auswirkungen Qualität wird in dem Unternehmen zu einem Standard Qualität wird als echter Faktor der Software-Entwicklung wahrgenommen 34

51 Lektion: Grenzen überschreiten Zeitpunkt Projekt werden an externe Unternehmen und Gruppen werden. Einwicklung an verschiedenen Standorten und evtl. in verschiedenen Zeitzonen. Integration Projektergebnisse werden zusammengefügt. Releasezyklen der Teilprojekte müssen abgestimmt werden. Umfangreiche Schnittstellen oder Abhängigkeiten existieren. Resultat Die Qualität der einzelnen Teile bestimmt im wesentliche die Erfolgsbeurteilung des Gesamten! Fehlende Qualität in Teilen können gravierende Auswirkung haben. 35

52 Lektion: Grenzen überschreiten Lösung Umfassende Klärung und Einflussnahme des Auftraggebers auf das Buildmanagement der Partner. Frühzeitige Klärung der QS Ansprüche und der Maßnahmen diese herzustellen. Einführung von QS-Systemen die den Entwicklungsstand begleiten. Review der QS-Maßnahmen und Systeme Hilfe vor Ort anbieten und annehmen. evtl. Infrastruktur selber betreiben und Mitarbeiter zur Betreuung bereitstellen. 36

53 Lektion: Grenzen überschreiten Probleme: Ohhje! Aus der guten Ideen werden schnell formale Hürden. Die Idee Qualität zu schaffen, darf nicht zum Mittel der Kontrolle verkommen. Aktive Hilfe ist gefragt und erkennen welche kleinen Hilfestellung schon riesige Wirkung haben. Qualität herzustellen braucht Zeit und einen Plan der dieses Ziel immer berücksichtigt. Kredite aufnehmen hilft nicht, aus man ist bereit die Tilgung zu leisten. Stellen Sie sich auf einige ernsthafte Auseinandersetzung ein. Sie brauchen jede Menge kleine gute Ideen und einen flexiblen Rahmen. Geld, Zeit und starke Mitarbeiter sind gefragt. 37

54 Tipps Klein starten und den Wachstum planen Team aufklären und Hilfestellung bieten Werkzeuge mit bedacht einführen. Organisation muss mit den Anforderung wachsen Automatisierung umsetzen wo sie hilft. Verteilte Strukturen arbeiten besser wenn die Partner transparent und verlässlich zusammenarbeiten. CC- ist ein nützliches Werkzeug das aber einen individuellen Zuschnitt erforderlich macht. 38

55 Lessons Learned Es macht Spass Cruisecontrol muss als Service organisiert sein Das Team soll diesen Service nutzen und ihn nicht erstellen Erfolg kommt mit einem agilen Entwicklungsprozess Alle Teammitglieder müssen Cruisecontrol ernst nehmen Auch Manager sind Teammitglieder "Build Failed" müssen schnell behoben werden keine Fehler-Verharmlosung Kurze CheckIns inkl. Tests Development-Guidelines in Cruisecontrol abbilden CheckIns lesen & Source anschauen Als Committer ist man auch Autor 39

56 Danke Michael Kloss Peter Roßbach 40