Configuration Management (Fokus: Version-Controlling) – Best Pracitces
- 1. Configuration Management (Fokus: Version Controlling) Best Pracitces Author: Artem Kaftanenko B-S-S GmbH, Eisenach; Datum: 09.12.2011
- 2. Herausforderung: Softwareentwicklung hohe Änderungsanfälligkeit gegenüber » Anforderungen » Personal » Werkzeuge hohe Anforderungen bzgl. » der Qualität » den Lieferterminen » der optimalen Aufwänden hohe Komplexität der entwickelnden Software 2
- 3. Lösung: Software Configuration Management Software Configuration Management (SCM) (Konfigurationsmanagement) » ist eine ManagementDisziplin » ist eine Spezialisierung des Configuration Management's Definition: „ ... is unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components, and products during the life of a system.” * Schlüsselbegriff: Configuration (Konfiguration) » = eine bestimmte Zusammensetzung einzelner Bestandteile » für SW-Entwickler = Version * http://ptgmedia.pearsoncmg.com/images/0321117662/samplechapter/hassch01.pdf, Stand vom 08.12.2011 3
- 4. Software Configuration Management - Ziele ... dient (dem Änderungen-Flut entgegen) » der Gewährleistung der hohen Produktqualität » der Erhaltung der Verwaltbarkeit des Projekts » ... alles übrige daraus ableitbar?! 4
- 5. Software Configuration Management - Mittel Formalisierung des Änderungsprozesses Sistematisierung der Produkt-Änderungen Dokumentation der essentiellen Zuständen » (finale bzw. Zwischen-Konfigurationen) standartisierte Prozeduren zum Durchführen des SCM » Configuration-Review » Configuration-Audit » Configuration-Control » ... 5
- 6. SCM - Managing Item: Configuration Item (1) Schlüsselbegriff: Configuration Item (CI) (Konfigurationseinheit) » (Gesamt-) Produkt » Teilprodukt, Produkt-Komponente - wenn das Produkt zu komplex ist. Eine natürliche Grenze der CI-Granularität: » Verwaltbarkeit 6
- 7. SCM - Configuration Item (2) In der englishsprachigen SCM-Literatur keinen Unterschied zw. dem Produkt bzw. Teilprodukt und den einzelnen Artefakten (z.Bsp. Dateien): alles ist ein Configuration Item » Begründung: alles kann auf einer bestimmten Abstraktions- /Granularitätsniveau als eine Konfigurationseinheit betrachtet werden Unpraktisch, da es keine Gewichtung gibt, um zu entscheiden » ob/wie ausführlich eine CI dokumentiert werden muss » ob/wie vollständig eine CI dokumentiert werden muss » ... Lösung: neuer Schlüsselbegriff - Konfigurationselement » für CI‘s, die selbstdokumentierend sind » Bsp.: Quellcode-Dateien, Spezifikation-Dokumente etc. 7
- 8. SCM - Konfigurationselemente (3) - Beispiele CI-Planung » Pläne, Meilensteine, Abnahmekriterien CI-Spezifikation » Anforderungen » interne/externe Schnittstellen » ... CI-Entwurf » Entwürfe, Festlegungen, ... CI-Umsetzung » Werkzeuge » Frameworks » Quellcode » Daten » Produkt-Releases CI-Dokumentation » Installation-, Wartung-, Endbenutzerdokumente 8
- 9. SCM - Configuration Item (4) - Charakteristik Um Überblick über all die Elemente während ihres Lebenslaufs nicht zu verlieren, ist wichtig: » CI-Identifikation - Benennung, Lokation » CI-Versionierung - Versionsnummer, seine Speicherung » CI-Abhängikeiten - insbesonders gerichtete und Parent-Child 9
- 10. SCM - Configuration Item (4) - Identifikation Benennung » intern ausgearbeitetes System » manuell / automatisiert Lokation » WiKi » Shared Folder (Files Storage) » spezialisierte Repositorien (Maven, ...) » Source Code Management (-SCM-) / Version Control Systems (VCS) Versionierung (Identifikation einer konkreten Instanz) » manuell » automatisiert, z.Bsp. mittels VCS 10
- 11. SCM - Configuration Item (5) - Versionierung Versionsnummer (Varianten) » Bestandteil des CI-Namens » Bestandteil des CI-Inhaltes » Meta-Info an einem gespeicherten CI Einflussfaktoren » Speichermedium » CI-Art (z.Bsp. keineswegs Namens-Bestandteil bei einer Quellcode-Datei) 11
- 12. SCM - CI (6) - Absicherung - Best Practices (1) Spezialfall: Software-Artefakte in einem VCS ... wann, wie oft? » jede in sich abgeschlossene logische Änderung » nur feingranulare, geprüfte Änderungen » so oft wie möglich Vorbereitung » erstmal auf die lokale Kopie den aktuellsten VCS-Stand mergen » Kompilierbarkeit / Ausführbarkeit / Konsistenz - prüfen - bei Bedarf wiederherstellen » einchecken 12
- 13. SCM - CI (7) - Absicherung - Best Practices (2) ... während dem Eincheck-Vorgang » Klare und sprechende Kontextinfos mitgeben: - CI-Elementen-Satz: - Artefakt-Identifikatoren - wer: der Verantwortliche - (zw. anderem für die Abgabe bzw. fürs spätere Bugs-Fixing) - wann: Zeitstempel, Version, Entwicklunglinie (Branch) - essentiell für die Traceability - was: Beschreibung der Änderungen - auf einem guten abstrakten Niveau! - warum: Anlass zu dieser Änderung - CR, BugFix, Feature, ... » Die ersten drei Punkte werden meistens Werkzeug-unterstützt. 13
- 14. SCM - Release-Management - Baseline Baseline » ~ Snapshot des aktuellen CI‘s-Bestands Baseline-Arten » Stabile Zwischenstände - hourly / nightly builds (automatisiert) » Release Candidates - RC's (manuell) » Final Releases (manuell) Nicht nur für Quellcode, sondern für alle Konfigurationselemente! 14
- 15. SCM - Release-Management - Best Practises einer Release-Verantwortliche Code-Freeze » organisatorisch (Rund-Email, ...) » technisch (Werkzeug-unterstütz, z.Bsp. durch einen Lock mittels VCS) Absprache » was muss ins Release » wie kann dies überprüft werden » Abnahmekriterien, qualifizierte(-r) Abnehmer Branching der Entwicklungsständen, zwecks ihrer Stabilisierung 15
- 16. SCM - Release-Management - Branching Dient der Teilung von Entwicklungslinien, z.Bsp.: » Feature branch » BugsFixes / Patches branch » Weiterentwicklung branch / trunk 16
- 17. ... Branching - Gefahren und Lösungen (1) Gefahren: » Zusammenführung (Merging) erforderlich - entstehen Bugs - besonders gefährlich: funktionelle Bugs » Entwicklungslinien gehen schnell auseinander - zu starke Unterschiede machen die Zusammenführung schwer oder sogar unmöglich 17
- 18. ... Branching - Gefahren und Lösungen (2) Lösungen (1) » reguläre Zusammenführung / Mergen - der Feature-branch auf Trunk - beim Erreichen des gewünschten Ergebnisses - der BugFixes/Patches-branch auf Trunk - bei jeder in sich abgeschlossenen logischen Änderung - des Trunks auf Feature-Brunch: bei jeder großen Änderung - => nach Bedarf, viele Gefahren, deswegen den Feature-branch kurzlebig halten - des Trunks auf BugFixes/Patches-branch - macht kaum Sinn - der Feature-branch auf BugFixes/Patches-branch und zurück - nach Bedarf 18
- 19. ... Branching - Gefahren und Lösungen (3) Lösungen (2) » Fixierung / Taggen - fester Baseline - sprechende Meta-Info, Kontext - durch Kommentarentext - durch Entwicklungsdokumente (auch CI-Elemente) - reproduzierbarer, referenzierbarer Meilenstand » evtl. Persistierung der Lieferungspaketen (SW, Dokumentation, ...) 19
- 20. ... Branching - Gefahren und Lösungen (4) Lösungen (3) - Werkzeugunterstützung » VCS-Clients - Inter-/Intra-Branches Navigation & Operationen » Continuous Integration - automatisierte Tests - frühzeitige Bugs-Erkennung - Benachrichtigungssystem - frühzeitige Erkennung der autom. festgestellten Problemen - reguläres und öfteres Ausrollen der stabilen Releases - kleinschrittliche Vorgehensweise; - kleine Schritte sind leichter handhabbar 20
- 21. ... Branching - Vorschlag v0.3.1.SNAPSHOT v0.3.0.RC1 ... v0.3.0 v0.3.1 v0.4.0 v0.4.1 branches/v0.3 .../v0.4 patch/maintenance trunk development v0.3.0.RC1 v0.4.0 v0.3.0.SNAPSHOT v0.4.0.SNAPSHOT v0.5.0.SNAPSHOT Legende: Zwischenstand v0.3.0.RC1 Versionsnummer Vorgänge: Branch-Startpunkt patch Entwicklungslinie (logische) branchen feste Version v0.3 Entwicklungslinie (physische) mergen ... wird getaggt ... trunk / branch 21
- 22. ... Release - Vorschlag v0.3.1.SNAPSHOT v0.3.0.RC1 ... v0.3.0 v0.3.1 branches/v0.3 patch/maintenance trunk development v0.3.0.RC1 v0.3.0.SNAPSHOT v0.4.0.SNAPSHOT Ausgangsdaten » gewünschter Stand im entsprechenden Trunk / Branch eingecheckt » gewünschte Versionsnummer: Final Release: v<MAJOR.MINOR.0> oder v<MAJOR.MINOR.0.RC1> Patch Release: v<MAJOR.MINOR.PATCH> oder v<MAJOR.MINOR.PATCH.RCx> 22
- 23. ... Release - Vorschlag - Final Release Vorgehensweise 1. auf dem trunk (Release-Erstellung): • die Versionsnummer in den entsprechenden Artefakten anpassen • den Stand bauen/vollständig testen und anschließend einchecken • das gebaute/getestete Release-Lieferungspaket extern absichern • den Stand taggen; empfohlener Tagname: v<current-trunk-version> • den Stand branchen; empfohlener Branchname: v<MAJOR.MINOR> 2. auf dem branch (Vorbereitung der Patch-Entwicklkungslinie): • die Versionsnummer in den entsprechenden Artefakten anpassen • <MAJOR.MINOR.1.SNAPSHOT> oder <MAJOR.MINOR.0.RC2-SNAPSHOT> • den Stand bauen/vollständig testen und anschließend einchecken • (optional) Stand taggen; empfohlener Tagname: v<current-branch-version> 3. auf dem trunk (Vorbereitung der Weiterentwicklkungslinie): • die Versionsnummer in den entsprechenden Artefakten anpassen: • <next-MAJOR.next-MINOR.0.SNAPSHOT> • den Stand bauen/vollständig testen (optional) und anschließend einchecken • (optional) Stand taggen; empfohlener Tagname: v<current-trunk-version> 23
- 24. ... Release - Vorschlag - Patch Release Vorgehensweise 1. auf dem branch (Release-Erstellung): • die Versionsnummer in den entsprechenden Artefakten anpassen • den Stand bauen/vollständig testen und anschließend einchecken • das gebaute/getestete Release-Lieferungspaket extern absichern • den Stand taggen; empfohlener Tagname: v<current-branch-version> 2. auf dem branch (Vorbereitung der Patch-Entwicklkungslinie): • die Versionsnummer in den entsprechenden Artefakten anpassen • <MAJOR.MINOR.next-PATCH.SNAPSHOT> oder • <MAJOR.MINOR.PATCH.next-RC-SNAPSHOT> • den Stand bauen/vollständig testen (optional) und anschließend einchecken • (optional) Stand taggen; empfohlener Tagname: v<current-branch-version> 24
- 25. SCM - Fragen? Noch Fragen? 25
- 26. Vielen Dank! Microsoft „Partner of the year 2010“ Finalist Ausgezeichnet von Gartner als „Cool Vendor 2010“ in Content Management B-S-S Business Software Solutions GmbH Wartburgstrasse 1 99817 Eisenach/Germany Tel. +49 3691 709000 Mail kontakt@b-s-s.de Web www.b-s-s.de Die Wartburg in Eisenach … 26