Business Value-Driven Management and IT Consulting. Erfolgreiches Build- und Release-Management in großen Projekten

Transkript

1 Business Value-Driven Management and IT Consulting Erfolgreiches Build- und Release-Management in großen Projekten Stefan M. Heldt Holger Koschek Holisticon AG 20. April

2 Agenda Konfigurationsmanagement Build Management Eclipse 3.2, Equinox und OSGi Release Management Versionierung und Roll-out Der Open-Source-Werkzeugkasten Fazit Diskussion 2007 Holisticon AG 2 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

3 Die Build am Sonntag -Redaktion Stefan M. Heldt Projektmanager (GPM-zertifiziert) Softwarearchitekt Build/Release Manager Java EE Holger Koschek Softwarearchitekt Build/Release Manager Java EE Technische Dokumentation Unternehmensportale Co-Autor Co-Autoren Gutachter Co-Autor 2007 Holisticon AG 3 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

4 Kennen Sie das nicht auch...? 2007 Holisticon AG 4 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

5 Konfigurationsmanagement Sichere Verwaltung Transparenter Zugriff sicher Kontrollierte Produktion aller Ergebnisse (Artefakte) eines (Software-)Projekts. transparent kontrolliert komplett 2007 Holisticon AG 5 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

6 Ziele und Maßnahmen des Konfigurationsmanagements Kommunikation Meritokratie Revisionssicherheit Änderungen kontrollieren Produktivität steigern Qualität sicherstellen Transparenz verbessern Modultests Metriken Fehlermanagement Standardisierung Projektautomatisierung Projekt- Homepages nach G. Popp: Konfigurationsmanagement mit Subversion, Ant und Maven 2007 Holisticon AG 6 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

7 Disziplinen des Konfigurationsmanagements Konfigurationsmanagement Build-Management Testmanagement Qualitätsmanagement Release-Management nach G. Popp: Konfigurationsmanagement mit Subversion, Ant und Maven 2007 Holisticon AG 7 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

8 Es geht doch auch ohne! Ich weiß, wie ich meine Software baue. Die Releasefrequenz ist oft gering. Aber weiß das auch die Kollegin? Und der Kunde? Build- und Release-Management kostet nur Geld. Aber sie steigt nicht selten im Verlauf eines Projektes! Kurzfristig ja, aber mittel- bis langfristig spart es Geld Holisticon AG 8 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

9 Build-Management vs. Release-Management Build-Management Übersetzen, Testen und Bereitstellen der Software (Compile Build Test Deploy) Auflösen von (internen/externen) Abhängigkeiten verschiedener Module Release-Management Definition der Liefergegenstände einer Softwareversion (Code, Skripte, Tests, Dokumentation, ) Prüfen der Liefergegenstände auf Vollständigkeit und Kompatibilität der Module Planen und Durchführen der Prozesse zur Auslieferung der Software (Merge, Code Freeze, Integrationstest, Roll-out) 2007 Holisticon AG 9 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

10 Versionsverwaltung Verschiedene Module möglichst identische Struktur standardisierte Build-Infrastruktur projektspezifische Konfiguration projektspezifisches Build-Skript ruft zentralen Build-Prozess Konfiguration statt Scripting (Maven-Ansatz) 2007 Holisticon AG 10

11 Versionsverwaltung CVS / Subversion / ClearCase /? egal Hauptsache, die Entwickler beherrschen das Werkzeug! eine falsch benutzte Versionsverwaltung ist schlimmer als gar keine defekte Branches falsche Merges Reserved Check-out und ab in den Urlaub! Open Source ist gut, aber auch ClearCase hat seine Berechtigung Entwicklung an verteilten Standorten Replikation des Repository 2007 Holisticon AG 11 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

12 Die hohe Kunst des Branch & Merge Organisation der Branches modulspezifisch Namen ausrichten an den Funktionen, nicht an den Versionen Branch- und Mergepunkte zentral dokumentieren Guten Tag! setzt man vor dem Branch vor dem Merge (in HEAD und Branch) nach dem Merge 2007 Holisticon AG 12

13 Die hohe Kunst des Branch & Merge Verwendung des HEAD für die Weiterentwicklung der nächsten Version + Branch nur bei Bug Fixes notwendig nur eine Entwicklungslinie für Bug Fixes (Flying Fish Approach) + parallele Weiterentwicklung in Branches nach Merge kein Hot Fix mehr möglich! erfordert disziplinierte Entwickler (HEAD ist für die Weiterentwicklung tabu) 2007 Holisticon AG 13 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

14 Der Regelkreis des Build- und Release- Prozesses Entwicklung Entwicklertest Freigabe Dokumentation Änderungsfreigabe (Check in) Qualitätskontrolle (Metriken, Testüberdeckung) Integrationstest 2007 Holisticon AG 14

15 DasDie Build-Ergebnisse Die gewünschten Build-Ergebnisse sind abhängig vom Kunden : Entwickler, CruiseControl, Nightly Build, Produktion Anwendungsfall: Übersetzen, Testen, Archivieren, Produzieren Beispiele: Ein Entwickler sollte in seiner Entwicklungsumgebung nur die Interfaces anderer (Teil-)Projekte sehen Zum Testen braucht der Entwickler die implementierenden Komponenten Die Produktion ist nicht an den Unit-Tests interessiert 2007 Holisticon AG 15 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

16 Software-Baumarkt Der Kunde baut die Software selbst Auslieferung eines Source-Pakets Bauen des Binary-Pakets (Build) in der Zielumgebung 2007 Holisticon AG 16

17 Die redundanzfreie Entwicklungsumgebung Entwickler müssen viele Einstellungen mehrfach vornehmen, z.b. und zwar Abhängigkeiten zu (bestimmten Versionen von) externen Bibliotheken Abhängigkeiten zu anderen (Teil-)Projekten Compiler-spezifische Einstellungen in ihrer Entwicklungsumgebung Gefahr von Inkonsistenzen für den zentralen Build-Prozess in der Entwicklungsumgebung läuft es, und trotzdem bricht der Build 2007 Holisticon AG 17

18 Eclipse 3.2, Equinox und OSGi Das Equinox Technology Project wurde ins Leben gerufen, um eine neue Ablaufumgebung für Eclipse zu definieren und implementieren Mit Eclipse 3.0 M6 wurde die Eclipse-Ablaufumgebung komplett auf eine OSGi-kompatible Umgebung umgestellt Einige Ergebnisse dieser Entwicklung fanden Eingang in das Eclipse OSGi Framework Das Equinox Technology Project wurde in das Equinox Eclipse Project überführt Eclipse (Top-level) project PDE Plug-in development environment JDT Java development tools Equinox an OSGi framework Platform 2007 Holisticon AG 18

19 Eclipse 3.2, Equinox und OSGi OSGi Service Platform [ ] a standardized, component oriented, computing environment for networked services that is the foundation of an enhanced service oriented architecture. Skalierbar von Embedded Devices bis zur Serverfarm Breites Anwendungsspektrum Telematik (z.b. BMW) Smart Phones (z.b. Nokia) Hausautomatisierung (z.b. Siemens) Softwaretechnik (z.b. Eclipse) 2007 Holisticon AG 19 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

20 Eclipse 3.2, Equinox und OSGi Equinox ist heute eine Implementierung der OSGi R4 Core Framework-Spezifikation Verantwortlich für die OSGi Framework-Implementierung aller Eclipse- Projekte Ein Plug-in in Eclipse entspricht einem OSGi-Bundle Eclipse Feature integriert o d e r eigenständig Equinox OSGi Container Plugin Plugin Bundle Bundle Nightly Build Test Integration Test 2007 Holisticon AG 21 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

21 Eclipse Plug-in Development Environment (PDE) Entwicklungs- und Build-Infrastruktur für Features und Plug-ins Editoren für Konfigurationselemente OSGi-Manifest (META-INF/MANIFEST.MF) build.properties Starten des Builds aus Eclipse heraus von der Kommandozeile (Headless Build) Callbacks erlauben das Erweitern des Standard-Buildprozesses an definierten Einstiegspunkten Beide Builds verwenden dieselben Konfigurationsinformationen! 2007 Holisticon AG 22

22 PDE Headless Build A B Platform Feature I Equinox an OSGi framework JDT Java development tools PDE Plug-in development environment Headless Build Feature 1 Build callbacks build Feature 1 Plug-in A Plug-in B Build callbacks 2007 Holisticon AG 23 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

23 Das Release-Puzzle: 1000 Teile ergeben ein B(u)ild Liefergegenstände einer Softwareversion Version ID Change Descriptions (mit Bezug auf Version ID) Dokumentation (Installationsanleitung, fachliche Release Notes) und natürlich die Software selbst Prüfen auf Vollständigkeit und Kompatibilität der Module möglichst automatische Prüfungen Begleitung technischer Integrationstests Dokumentation der Releases mit den Version IDs der einzelnen Module 2007 Holisticon AG 24

24 Messen Steuern Regeln Code-Metriken auf die sinnvolle Auswahl kommt es an Berechnung kostet Zeit und geht zu Lasten der Build-Turnarounds Einhaltung muss von den Entwicklungswerkzeugen weitgehend unterstützt werden (z.b. max. Zeilenlänge im Eclipse-Editor einstellen) Testüberdeckung JUnit-Tests sind gut aber testen sie wirklich alle Klassen/Methoden? Weitere Maßnahmen Peer Review 2007 Holisticon AG 25

25 Messen Steuern Regeln Metriken allein genügen nicht nicht nur sammeln, sondern auch auswerten! wirklichen Aufschluss geben nur die Trends einzelner Metriken Aufzeichnung und Auswertung über längere Zeiträume aus den Erkenntnissen der Metrik-Analyse müssen konkrete Maßnahmen abgeleitet und umgesetzt werden Trainings Richtlinien Neuzuordnung von Aufgaben 2007 Holisticon AG 26

26 Messen Steuern Regeln Commit/Checkin: Wann Was Wer? Update: Wann? Welche Änderungen kommen in welches Release? Wer darf Merges durchführen? Wer darf in welche Branches schreiben? Design Patterns, Best Practices 2007 Holisticon AG 27

27 Versionierung Was? Build-Ergebnisse (JAR, etc.) Konfigurationsdateien Softwarekomponenten und Strukturelemente (z.b. Eclipse-Features und Plug-Ins) Wann? Wie? nach jedem Build: Build-ID erhöhen (Bestandteil der Versionsnummer) Nach jeder Änderung Abhängig von der Änderung (Implementierung, Schnittstelle, Architektur) 2007 Holisticon AG 28

28 Das Eclipse-Versionsschema In Eclipse werden Versionsnummern aus drei Zahlen und einer Zeichenkette gebildet: major.minor.service.qualifier Jedes Segment hat eine eigene Bedeutung: the major segment indicates breakage in the API the minor segment indicates "externally visible" changes the service segment indicates bug fixes and the change of development stream the qualifier segment indicates a particular build Automatisch in die Versionsnummer des Plug-ins generierbar Bundle-Version: Holisticon AG 29 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

29 Rock'n'Roll-out Client-Roll-out in einem paneuropäischen Projekt 1 Client-Softwarepaket + 4 verschiedene Systemumgebungen + 4 verschiedene IT-Organisationen + 4 verschiedene Validierungsprozesse + 4 verschiedene Benutzerberechtigungskonzepte = eine Menge Probleme und viel Zeit 2007 Holisticon AG 30 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

30 Der Open-Source-Werkzeugkasten für das Build- und Release-Management Vorlage Heise-Verlag/c t Versionskontrolle CVS Subversion Build Management Ant Maven Continuous Integration JUnit CruiseControl Entwicklungsumgebung Eclipse SDK + Plugins 2007 Holisticon AG 31 stefan.heldt@holisticon.de, holger.koschek@holisticon.de

31 Fazit Dem Build- und Release-Management wird in vielen Projekten nicht der nötige Stellenwert eingeräumt Ziel: Lieferung der Software den Anforderungen entsprechend termingerecht kostengerecht qualitativ hochwertig Maßnahmen: weitgehend standardisierter und automatisierter Prozess für das Erstellen der Software sorgfältige und rechtzeitige Planung der Software-Releases 2007 Holisticon AG 32

32 Stefan M. Heldt Holger Koschek Holisticon AG 20. April Holisticon AG 33

33 Vielen Dank für Ihre Aufmerksamkeit 2007 Holisticon AG 34