Konfigurationsmanagement

Transkript

1 Konfigurationsmanagement Versionsverwaltung Oktober 2012, Robert Kolb

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

3 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

4 Configuration Management 4

5 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

6 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

7 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

8 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

9 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

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

11 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

12 Version Management 12

13 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 Visual Studio.NET Visual Studio.NET Visual Studio Visual Studio Visual Studio Visual Studio _MSC_VER ist ein Makro zur Unterscheidung der Compilerversion im Source Code 13

14 Übliches Versionierungsschema Major Release Number 1. Minor Release Number X.1 Revision (Patch) Number Build Number X.Y[.0] X.Y[.Z[.n]] V V V V Version shipped shipped Release Release

15 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

16 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

17 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

18 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

19 Branching Strategie future B B next release B next service pack B next hotfix Quelle: 19

20 Release Branching Advanced (Microsoft) RI RI B FI B FI FI FI B B RI Emergency Hotfix B FI RI Delete old hotfixes Quelle: Delete old releases 20

21 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

22 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

23 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

24 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

25 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

26 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

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

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

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

30 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

31 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

32 Aufgaben für das Selbststudium Skript Basiswissen SW-PM, Kapitel 9 Anleitung zu TortoiseSVN durcharbeiten oder Videos zu Git durcharbeiten: 32

33 Informations- und Bezugquellen Subversion TortoiseSVN Git Git TFS TFS Preview Übersicht 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

34 Fragen und Antworten 34