Konfigurationsmanagement

Konfigurationsmanagement Versionsverwaltung Oktober 2012, Robert Kolb

Themen Theorie Konfigurationsmanagement Versionierungsschema Varianten (Branches) Versionsverwaltung Praxis Konfigurationsmanagement am Beispiel - Subversion (TortoiseSVN), Git, TFS - TortoiseMerge / WinMerge 2

Lernziele Sie können die Begriffe Konfiguration, Baseline und Version erklären Sie haben mögliche Tools für die Versionsverwaltung kennen gelernt Sie haben WinMerge als mögliches Tool zur Zusammenführung von Versionen kennen gelernt 3

Configuration Management 4

Wozu Konfigurationsmanagement? Strukturierung des Änderungswesens Aufzeichnung der Entwicklungsgeschichte Überwachung der Änderungen und der Änderungsprozesse Fehlerkorrekturen und Festlegung der Auswirkungen auf einzelnen Versionen Überwachung der Arbeitsschritte in der Entwicklung und in der Produkte- Pflege 5

Konfigurationsmanagement gibt Antwort auf... (1) Welcher Kunde hat eine spezielle Version eines Produktes erhalten? Welche Hardware- und Systemsoftwarekonfiguration wird für eine geplante Produktversion benötigt? Wie viele Versionen des Produktes wurden erzeugt und wann? 6

Konfigurationsmanagement gibt Antwort auf... (2) Welche Versionen des Produktes sind betroffen, wenn eine spezielle Komponente geändert wird? Wie viele Änderungsanträge (Change Requests) oder Problem- Meldungen (Problem Reports) sind für eine spezielle Version noch unerledigt? Wie viele Fehlermeldungen liegen für eine spezielle Version vor? 7

Was ist eine Software-Konfiguration? Eine bekannte und freigegebene Menge von Software-Elementen (Entwicklungsdokumente, Software bis Hardware) zu einem bestimmten Produkte-Lebenszyklus. Konfiguration Dokumente SW-Elemente Werkzeuge - Projekt Dokumente - Spezifikationen - Design Dokumente - Test Dokumente - Manuals - etc. - Quellen-Elemente - Abgeleitete Elemente - Compiler, Linker, IDE - Betriebssystem(e) - Patches - Architekturen - Hardware - Libraries, SDKs, etc. 8

Was ist ein Software-Element? Jeder identifizierbare und maschinenlesbare Bestandteil eines entstehenden Produkts Eindeutige Bezeichnung (durch Version) Jede Änderung hat Einfluss auf die Bezeichnung 9

Klassifizierung der Software-Elemente Source-Code Ableitung mit Hilfe von Tool, z.b. Compiler Quellen- Element Abgeleitetes Element Source-Code Binary, Library etc. 10

Referenzkonfiguration (Baseline) Eine Referenzkonfiguration umfasst ein Zwischenergebnis zu einem bestimmten Zeitpunkt (in der Regel nach einem Meilenstein oder einer Phase) Anforderungskonfiguration Entwurfskonfiguration Produktkonfiguration Pflegekonfiguration Pflichtenheft OOA-Modell GUI-Modell Benutzerhandbuch + ODD-Modell + Source-Code + Object-Code + Binaries + geänderte Teile + neue Teile Definitionsphase Entwurfsphase Einführungsphase Wartungs- und Pflegephase Zeit 11

Version Management 12

Versionierungsschema für Produkte Produktversionen haben meist keinen direkten Zusammenhang mit der Versionierung im Source Code oder der Produktbezeichnung Beispiel Microsoft Visual Studio: Produkt Versionsnummer _MSC_VER Visual Studio 6.0 6 1200 Visual Studio.NET 2002 7 1300 Visual Studio.NET 2003 7.1 1310 Visual Studio 2005 8 1400 Visual Studio 2008 9 1500 Visual Studio 2010 10 1600 Visual Studio 2012 11 1700 _MSC_VER ist ein Makro zur Unterscheidung der Compilerversion im Source Code 13

Übliches Versionierungsschema Major Release Number 1. Minor Release Number X.1 Revision (Patch) Number Build Number X.Y[.0] X.Y[.Z[.n]] V 1.1.0 V 1.2.0 V 1.3.0 V 2.1.0 Version shipped shipped Release 1.2.0 http://en.wikipedia.org/wiki/software_versioning Release 2.1.0 14

Datei basierte History (z.b. Visual SourceSafe, CVS) Konventioneller, früher meist verwendeter Ansatz für Versionierung Jede Datei wird einzeln versioniert, d.h. nur eine Änderung an der Datei verändert ihre Versionsnummer (Revision) Grösster Nachteil: Zusammenhang der Dateiversionen untereinander fehlt 15

Bezeichnen von Versionen (Tagging, Labeling) Versuch, den grössten Nachteil von dateibasierter Histrory zu beheben. Beim Tagging werden verschiedene Dateien, welche zueinander im Kontext stehen, mit einer Bezeichnung (z.b. Release_1.0.1) versehen, damit sie in dieser Zusammenstellung (View) wieder aus dem Repository gelesen werden können. 16

Commit basierte History (z.b. Subversion, TFS, Git) Moderner Ansatz für Versionierung, berücksichtigt Kontext der Dateien. Eine Änderung am Repository (commit) verändert die globale Versionsnummer (Revision, Changeset), Dateien haben keine eigene Versionsnummer mehr. Pro Änderung können mehrere Dateien hinzugefügt, verändert oder gelöscht worden sein. Revision oder Changeset 17

Varianten (Branches oder Äste) Zeitlich nebeneinander liegende Ausprägungen von Software Elementen mit gleicher Basis Parallele Entwicklungslinien, nachträgliche Bug Fixes Unterschiedliche Implementierung derselben Schnittstelle Unterschied durch bedingte Übersetzung Ausgelegt auf unterschiedliche Systeme oder Hardware 18

Branching Strategie future B B next release B next service pack B next hotfix Quelle: http://vsarbranchingguide.codeplex.com/ 19

Release Branching Advanced (Microsoft) RI RI B FI B FI FI FI B B RI Emergency Hotfix B FI RI Delete old hotfixes Quelle: http://vsarbranchingguide.codeplex.com/ Delete old releases 20

Branches und Tags mit Subversion In Subversion besteht keine spezielle Funktion für Branching und Tagging. Anstelle dessen wird einfach eine Kopie des gewünschten Dateibaumes unter einem neuen Namen im Ordner "branches" bzw. "tags" angelegt. Hierbei wird jedoch kein Speicherplatz belegt. Gemäss Konvention werden danach die Dateibäume unter "tags" nicht mehr weiterverwendet, da sie nur als Markierungen dienen. Die Dateibäume unter "branches" werden hingegen weiterentwickelt und die darin vorgenommenen Änderungen fliessen meist wieder in die Hauptentwicklungslinie "trunk" zurück (Merging). Branches und Tags können problemlos gelöscht werden, wenn sie nicht mehr gebraucht werden. 21

Check out / Check in Processes Repository check out Working Copy (Sandbox) Code Code Repository Server Development Workstation modify Repository mod. Code check in Working Copy (Sandbox) mod. Code Repository Server Development Workstation 22

Version Control Model "Lock - Modify - Unlock" Locked check out Archiv (Repository) 1. check out (lock) V x.y Kopien File(s) gesperrt (locked) 2. modify 4. Version(en) des/der Files wird erhöht und abgespeichert 3. check in (unlock) Änderungen 23

Version Control Model "Copy - Modify - Merge" Concurrent check out Archiv (Repository) 1. check out (copy) V x.y Kopien Dateien nicht gesperrt 2. modify 4. Version des Repository wird erhöht und abgespeichert 3. commit (update / merge) Änderungen 24

Merge-Konflikte bei "Copy - Modify - Merge" Wenn mehrere Entwickler parallel an einem Projekt arbeiten, kann es vorkommen, dass Änderungen an der gleichen Datei vorgenommen werden. Sind diese Änderungen an der gleichen Stelle der Datei, so führt dies zu einem Merge-Konflikt für die anderen Entwickler, sobald der erste Entwickler seine Änderungen ins Repository eingecheckt hat. D.h. jeder andere Entwickler kann seine Änderungen erst dann ins Repository einchecken, wenn er seinen Merge-Konflikt gelöst hat. Der Merge-Konflikt muss manuell gelöst werden, da das Tool nicht selbst entscheiden kann, welche Änderung ins Repository übernommen werden soll. Um diesen Merge-Konflikt möglichst einfach zu lösen, werden entsprechende Hilfsmittel bereit gestellt (z.b. TortoiseMerge oder WinMerge). Problematisch sind binäre-dateien (z.b. Word), hier den Lock verwenden 25

Hilfsmittel für Bearbeitung von Merge-Konflikten Links: Änderungen der Anderen gegenüber der Ausgangsdatei Rechts: Meine Änderungen gegenüber der Ausgangsdatei Unten: Zusammengeführte Änderungen und noch nicht gelöste Merge-Konflikte 26

Repository Konzept lokal z.b. Subversion, TortoiseSVN, VSS 27

Repository Konzept zentral z.b. CVS, Subversion, TortoiseSVN, Perforce, TFS 28

Repository Konzept dezentral (distributed) z.b. Git, Mercurial 29

Wesentliche Unterschiede von Git zu anderen VCS Repository zu Projekt Git: 1:1 Subversion, TFS 1:n Grund: Datentransfer bei Git für initial clone möglichst gering halten. Commit, Check-In Git: 2 commit check-in, 1. lokal, 2. zum Master-Repository Subversion, TFS 1 commit check-in Branches erstellen Git: ohne Master-Repository möglich Subversion, TFS nur mit Verbindung zum Repository möglich 30

Wesentliche Unterschiede von TFS zu anderen VCS TFS ist mehr als ein Tool zur Versionsverwaltung wie Subversion oder Git, es enthält: Versionsverwaltung Build Engine (TFS-Builds) Workflow Engine für Entwicklungsprozesse (Issue Tracking, Work Items) Dokumentationsverwaltung (SharePoint) Reporting Integration mit Test-Automation Clients: Visual Studio, Team Explorer, Excel, Project, Office, Outlook, Web, Eclipse Backend für TFS ist der MS-SQL Server 31

Aufgaben für das Selbststudium Skript Basiswissen SW-PM, Kapitel 9 Anleitung zu TortoiseSVN durcharbeiten http://pmcm.frox.com/randd_8208_tortoisesvn.pdf oder Videos zu Git durcharbeiten: http://git-scm.com/documentation 32

Informations- und Bezugquellen Subversion http://subversion.apache.org/ TortoiseSVN http://tortoisesvn.net/ Git http://git-scm.com/ Git http://stefanimhoff.de/notiz/einstieg-in-git-als-versionskontrollsystem/ TFS http://www.microsoft.com/visualstudio/eng/products/visual-studio-team-foundation-server-express TFS Preview http://tfspreview.com/ Übersicht http://en.wikipedia.org/wiki/comparison_of_revision_control_software Subversion und Git sind Open Source und daher frei erhältlich. Für TFS gibt es die kostenlose Express-Version, welche die Arbeit für bis zu fünf Entwickler zulässt. 33

Fragen und Antworten 34