OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
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
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
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
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
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
