GPM Region Düsseldorf/Rhein-Ruhr

Transkript

1 GPM Region Düsseldorf/Rhein-Ruhr PM-Tag 2011 am mit dem Vortrag : Kontinuierliche Integration in Standortübergreifenden Projekten

2 Inhalt 1. Foliensatz der Veranstaltung am bei der IT.NRW Mauerstr Düsseldorf 2. Kontaktdetails des vortragenden Unternehmens 3. Kontaktdetails GPM/GPM Region Düsse eldorf-rhein/ruhr Hinweis: Der Inhalt dieser Präsentation muss nicht die Meinung der GPM Deutsche Gesellschaft für Projektmanagement e.v. darstellen. Alle Rechte und Pflichten obliegen dem Präsentierenden ( Gero Seifert, TATA CONSULTANCY SERVICES, Düsseldorf) KOMPETENZ

3 Kontinuierliche Integration in Standortübergreifenden Proje kten PM-Tag 2011 GPM Düsseldorf, Dortmund/Ruhrgebiet Version Sep-2011 Gero Seifert

4 Vortragender: Gero Seifert Tata Consultancy Services (TCS) Programmleiter bei TCS D dorf seit 2008 Seit 20 Jahren in der SW Entwicklung tät tig Über 14 Jahre Erfahrung mit indischem Offshoring 6 Jahre Management agiler Projekte Maßgeblich beteiligt bei der Einführung agiler Praktiken bei Nokia, NSN und TCS. Aktuelles agiles Projekt: VW Car Configuration Services Diplom Informatiker, Universität Erlangen Nürnberg Kontinuierliche Integration (CI) in Standortübergreifenden Projekten

5 Dieser Vortrag gibt Hinweise, wie Sie I. den Begriff Kontinuierliche Integration (CI) verstehen können. II. überschauen, wie komplex die Einführung von CI in Ihren Projekten wäre. III. einschätzen, in wie weit Ihre Projekte von CI profitieren würden.

6 Übers sicht 16:30 17:10 1 Begriffsklärung Vor- und Nachteile Fünf Schritte zur Einführung Zusammenfassung Diskussion

7 CI betrifft IT T Projekte die SW Komponenten und Module entwickeln oder warten, die zusammen ein Produkt bilden sollen. CI betrifft nicht IT Projekte, die primär dazu dienen, fertige SW Produkte bei einzelnen Kunden zu integrieren oder zu konfigurieren (z.b. SAP, Siebel).

8 CI ist nicht nur Ver rsionsverwaltung die SW Entwickler eines Teams verwenden, um ihren Quellcode bei Bedarf schnel l, konsistent und einheitlich abzugleichen.

9 CI ist eine e Praktik von SW Entwicklungsteams, die ihre Artefakte* regelmäßig, häufig und vollständig untereinander abgleichen und ihr Produkt nach jedem Commit** automatisch hbauen und testen. * Artefakte zum Bauen und Testen des lauffähigen SW Produktes (Quellcode, Build Skripte, Testdaten, Testfälle, ) ** Commit ist die Freigabe von eigenen n Artefakten für alle Teammitglieder über die Versionsverwaltung

10 CI ist eine e Praktik und erfordert das Praktizieren aller Teammitglieder. Das bedeutet fast imm er einen Kulturwandel. SW Werkzeuge sind dabei notwendig, aber nicht hinreichend.

11 Über rsicht Begriffsklärung Vor- und Nachteile Fünf Schritte zur Einführung Zusammenfassung Diskussion

12 Verwendung für Demo, Test oder Vertriebszwecke Vort teile 1. Geringeres Risiko Keine großen, unkalkulierbare en Integrationsschritte 2. Geringere Fehlerkosten Schnelle, frühzeitige Fehlerentdeckung und behebung 3. Höhere Mitarbeitermotiv vation Sichtbar wachsendes System gleichzeitiger Fehler und eine beherrschbare Anzahl 4. Verfügbarkeit des aktuellsten Produktes

13 Nachteile / Hürden 1. Kulturwandel um Entwicklungsteams für kleine Integrationsschritte und hohe Testautomation zu gewinnen 2. Hardwarekosten um einen schnellen Build (mit Tests) sicherzustellen 3. Anfängliche Entwicklungskosten um die erforderliche Infrast truktur aufzubauen 4. Wartungskosten für Legacy Code die durch CI deutlich schneller sichtbar werden

14 Über rsicht Begriffsklärung Vor- und Nachteile Fünf Schrit tte zur Einführung 1. Versionsverwaltung 2. Gleiche Umgebungen 3. Automati ischer Build 4. Weitere Testautomation 5. Systematische SITs* Zusammenfassung Diskussion * System und Integrationstests

15 Schritt 1: Versionsverwaltung

16 Schritt 1: Versionsverw waltung Eine Versionsverwaltung einsetzen NotwendigeFeatures sindato omare Commits, Rollbacksund gleichzeitiges Edieren Ein Archiv für alle Artefak kte verwenden Inklusive Build Tools oder IDE Setup Dateien Fein granulare Operationen unterstützen Idealerweise: parallele Änder rungzweiermethoden einer Klasse ohne anschließenden Merge

17 Schritt 1: Versionsverw waltung Ausreichend Bandbreite zur Verfügung stellen Breitbandiger Internetzugang g ist zb z.b. in Indien sehr teuer, aber für einen schnellen Abgleich mit dem Archiv unerläßlich

18 Schritt 1: Versionsverw waltung Nur aus dem Archiv bauen Keine Dateien nehmen, die nu ur lokal beim Entwickler liegen Änderungen in kleinen Schritten committen Durch Architektur Abhängigkeiten minimieren Versionierte Schnittstellen, fei in granulare Objekte, Nicht branchen! Versions Verzweigungen nur aus triftigen Gründen erlauben Konfigurierbarkeit statt kundenspezifischem Code realisieren Täglich Commitfrequenz und größe messen!

19 Schritt 2: Gleiche Umgebungen

20 Schritt 2: Gleiche Umg gebungen Gleiche Entwicklungstools verwenden ZB Z.B. Compiler und IDE Versio onen Einheitliche Testumgebungen pflegen Z.B. Patchlevel der Betriebssysteme, Datenbankversionen Spezifische Umgebungen n im Projekt einplanen Auch wegen der Budgetbewilligung zu Projektbeginn nötig

21 Schritt 2: Gleiche Um mgebungen Verfügbarkeit und Kosten von HW & SW prüfen Siekönnen je nach Standort stark variieren Vorlaufzeiten für Genehmigungen einplanen Je nach Standort muss die Verwendung von HW oder SW genehmigt werden. Dies dauert sehr unterschiedlich lang Sicherheitsrichtlinien berücksichtigen Dazu müssen oft Umgebunge en speziell konfiguriert werden

22 Schritt 3: Automatischer Build

23 Schritt 3: Automatisch her Build One button Build entwickeln Das lauffähig SW Produktesd durch ein einziges Kommando vollständig generieren Automatische Modultests aufnehmen Build Ergebnis allgemein sichtbar machen CI Tool (CruiseControl, Hudson, Jenkins, ) einsetzen, das die Ergebnisse aufbereitet und d arstellt bzw. per Mail verschickt

24 Schritt 3: Automatisch her Build Build Manager und Proxys benennen Sie dürfen Entwickler anweise en, den Build zu reparieren Kompetenz verteilen Der automatische Build ist eine kritische Resource und muss unabhängig vom Standort hoch verfügbar sein Dauer minimieren Build Dauer sollte inklusive Modultests unter zwei Minuten bleiben: inkrementell bauen, Modultests optimieren,

25 Schritt 3: Automatisch her Build Lasst den Build heile! Esbleibt dabei: häufigkleine Änderungen committen Build Reparatur hat höchste Priorität Im Zweifelsfall macht der Build Manager einen Rollback Build Manager und Proxy ys agieren als Coaches In dieser Rolle erfährt man gut die Bedeutung des Builds Bei jedem Build die Dauer, Testabdeckung, und Anzahl der Abbrüche messen!

26 Schritt 4: Weiteree Testautomation 200 Einmaliger SIT* zum 180 Entwicklungsende Fehlerstatistik Total Low Medium High Very High Kontinuierlicher SIT* * System und Integrationstest Total Low Medium High Very High

27 Schritt 4: Weitere Test tautomation System und Integrationstests (SIT) automatisieren Evtl. Test Frameworks wie Fit tnesse oder Twist verwenden Build um Smoke Tests erweitern Dazu installiert der One button Build das SW Produkt zunächst automatisch in einer Referenzumgebung Vor jedem Commit testen! Jeder Entwicklertestet testet seine Änderungen vor dem Commit mit den zusätzlichen automatischen Tests im Sandkasten Testinfrastruktur erweite rn Haben die Entwickler genügend Sandkästen?

28 Schritt 4: Weitere Test tautomation Testleiter plant und koordiniert Lücken in der Testabdeckung schließen, Wiederverwendung von Tests fördern, Build Dauer minimieren Mit Smoke Tests dauert der Build erheblich länger: stärkere HW einsetzen, inkrementell bauen, Smoke Tests parallel ausführen,

29 Schritt 4: Weitere Test tautomation Entwickler lernen SITs zu automatisieren Dazu müssen viele Entwickler erst Testgrundlagen erlernen Entwickler schreiben automatisierte SITs Was wird aus den traditionellen Testern? Welcher Grad an Testautomation läßt sich durchsetzen? Bei jedem Build die Dauer, Testabdeckung (für SIT) und Anzahl der Abbrüche messen!

30 Schritt 5: Systematische SITs

31 Schritt 5: Systematisc he SITs SITs nach Aufgabe und Dauer klassifizieren ZB Z.B. je eine Testklasse für Stab bilitäts und Performancetests Builds für Testklassen aufsetzen Beinhaltet die Planung, wannn wo welche SITs laufen sollen; evtl. Testinfrastruktur erweitern

32 Schritt 5: Systematisc he SITs Teams sind für Featuregruppen verantwortlich Im Agilen sind cross function nal teams üblich Tests nach Featuregruppen klassifizieren Dies bedeutet fast immer redundantes Testen In den Tools Featuregrup pen unterstützen Von der Anforderungserfassung bis zum vollautomatisch generierten Testbericht

33 Schritt 5: Systematisc he SITs Teammitglieder pflegen Featuregruppen Angabe der zugehörigen FeaturegruppeninUserStories Stories, in Commits, in SITs, Bei jedem Build messen (Dauer, Abdeckung, Anzahl Abbrüche) nach Featuregruppe

34 Über rsicht Begriffsklärung Vor- und Nachteile Fünf Schritte zur Einführung Zusammenfassung Diskussion

35 Zusammenfassung 1. Compilieren & Linken 2. Modultests 4. Smoke Tests und SITs 3. Installation 5. Report Versionsverwaltungs und Build Server Referenzumgebung Development Environment

36 Zusamme enfassung Schwierigkeitsgrad Automatisierung auf SIT ausdehnen Versionsverwaltung sachgemäß verwenden Build automatisieren Umgebungen vereinheitlichen SITs systematisieren

37 GERO SEIFERT Program Manager TATA CONSULTANCY SERVICES Tata Consultancy Services Deutschland GmbH Heltorfer Straße 1, D Düsseldorf Mobile , Fax Phone gero.seifert@tcs.com website: Diskussionssion Think Agile Think Düsseldorf

38 Kontakt GPM Deutsche Gesellschaft für Projektmanagement e.v. Hauptgeschäftsstelle Nürnberg FrankenCampus Frankenstraße Nürnberg Tel.: +49 (0) Fax: +49 (0) Internet: Veranstaltungshinweise der GPM Region Düsseldorf/Rhein-Ruhr Bei Fragen zum Veranstaltungsprogramm oder möglichkeiten können Sie sich gerne an die zu Netzwerk- Region Düsseldorf / Rhein-Ruhr Guido Bacharach Dieter Staudt Tel.: +49 (0) (0) g.bacharch@gpm-ipma.de d.staudt@gpm-ipma.de wenden KOMPETENZ