Configuration Management              (Fokus: Version Controlling)                         Best PracitcesAuthor: Artem Kaf...
Herausforderung: Softwareentwicklung  hohe Änderungsanfälligkeit gegenüber  » Anforderungen  » Personal  » Werkzeuge  hohe...
Lösung: Software Configuration Management    Software Configuration Management (SCM)    (Konfigurationsmanagement)      » ...
Software Configuration Management - Ziele  ... dient (dem Änderungen-Flut entgegen)   » der Gewährleistung der hohen Produ...
Software Configuration Management - Mittel  Formalisierung des Änderungsprozesses  Sistematisierung der Produkt-Änderungen...
SCM - Managing Item: Configuration Item (1)  Schlüsselbegriff: Configuration Item (CI)  (Konfigurationseinheit)   » (Gesam...
SCM - Configuration Item (2)  In der englishsprachigen SCM-Literatur keinen Unterschied zw.  dem Produkt bzw. Teilprodukt ...
SCM - Konfigurationselemente (3) - Beispiele  CI-Planung   » Pläne, Meilensteine, Abnahmekriterien  CI-Spezifikation   » A...
SCM - Configuration Item (4) - Charakteristik  Um Überblick über all die Elemente während ihres  Lebenslaufs nicht zu verl...
SCM - Configuration Item (4) - Identifikation  Benennung   » intern ausgearbeitetes System   » manuell / automatisiert  Lo...
SCM - Configuration Item (5) - Versionierung  Versionsnummer (Varianten)   » Bestandteil des CI-Namens   » Bestandteil des...
SCM - CI (6) - Absicherung - Best Practices (1)Spezialfall: Software-Artefakte in einem VCS   ... wann, wie oft?    » jede...
SCM - CI (7) - Absicherung - Best Practices (2)   ... während dem Eincheck-Vorgang   » Klare und sprechende Kontextinfos m...
SCM - Release-Management - Baseline  Baseline   » ~ Snapshot des aktuellen CI‘s-Bestands  Baseline-Arten   » Stabile Zwisc...
SCM - Release-Management - Best Practises  einer Release-Verantwortliche  Code-Freeze   » organisatorisch (Rund-Email, ......
SCM - Release-Management - Branching  Dient der Teilung von Entwicklungslinien, z.Bsp.:  » Feature branch  » BugsFixes / P...
... Branching - Gefahren und Lösungen (1)  Gefahren:   » Zusammenführung (Merging) erforderlich      - entstehen Bugs     ...
... Branching - Gefahren und Lösungen (2)  Lösungen (1)   » reguläre Zusammenführung / Mergen      - der Feature-branch au...
... Branching - Gefahren und Lösungen (3)  Lösungen (2)   » Fixierung / Taggen       - fester Baseline       - sprechende ...
... Branching - Gefahren und Lösungen (4)  Lösungen (3) - Werkzeugunterstützung   » VCS-Clients      - Inter-/Intra-Branch...
... Branching - Vorschlag                              v0.3.1.SNAPSHOT            v0.3.0.RC1 ... v0.3.0            v0.3.1 ...
... Release - Vorschlag                             v0.3.1.SNAPSHOT            v0.3.0.RC1 ... v0.3.0            v0.3.1bran...
... Release - Vorschlag - Final Release  Vorgehensweise   1.   auf dem trunk (Release-Erstellung):        • die Versionsnu...
... Release - Vorschlag - Patch Release  Vorgehensweise   1.   auf dem branch (Release-Erstellung):        • die Versionsn...
SCM - Fragen?                Noch Fragen?                               25
Vielen Dank!  Microsoft „Partner of the year 2010“ Finalist  Ausgezeichnet von Gartner als „Cool Vendor 2010“ in Content M...
Upcoming SlideShare
Loading in...5
×

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

417

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
417
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Configuration Management (Fokus: Version Controlling) Best PracitcesAuthor: Artem KaftanenkoB-S-S GmbH, Eisenach; Datum: 09.12.2011
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. SCM - Release-Management - Branching Dient der Teilung von Entwicklungslinien, z.Bsp.: » Feature branch » BugsFixes / Patches branch » Weiterentwicklung branch / trunk 16
  17. 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. 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. 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. 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. 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. 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. 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. 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. 25. SCM - Fragen? Noch Fragen? 25
  26. 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

×