• Save
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Configuration Management (Fokus: Version-Controlling) – Best Pracitces

  • 544 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
544
On Slideshare
544
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Configuration Management (Fokus: Version Controlling) Best PracitcesAuthor: Artem KaftanenkoB-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 Managements 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 - RCs (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.1branches/v0.3 .../v0.4 patch/maintenance trunk development v0.3.0.RC1 v0.4.0v0.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.1branches/v0.3 patch/maintenance trunk development v0.3.0.RC1v0.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 ManagementB-S-S Business Software Solutions GmbHWartburgstrasse 199817 Eisenach/GermanyTel. +49 3691 709000Mail kontakt@b-s-s.deWeb www.b-s-s.de Die Wartburg in Eisenach … 26