Branching und Merging mit Visual Studio Team System

Transkript

1 Branching und Merging mit Visual Studio Team System

2 IN EINER IDEALEN WELT GIBT ES Ein Entwicklungsteam Ein Projekt welches deployt werden muss Eine Deadline Kunden warten bis das Projekt komplett fertig ist Jeder Kunde migriert sofort zur neuen Version Nach einem werden keine Defekte mehr gefunden Version 1 Version 2 Version 3

3 IN DER REALEN WELT GIBT ES (UNGLÜCKLICHERWEISE) Teams die parallel an einem Projekt arbeiten Mehrere Projekte in unterschiedlichen Versionen die deployt werden müssen Test-Teams die Defekte in aktuellen und alten Versionen finden Experimentelle Entwicklung am Projekt Version 3 Version 1 Team A Team B Defekte Version 2

4 PARALLELE ENTWICKLUNG Mehrere Instanzen des Projekts um die Aufgaben der realen Welt zu lösen In unterschiedlichen Versionen Für Arbeiten an verschiedenen Bereichen Um diese Instanzen zu erzeugen wird Branching genutzt Version 1.1 Version 1 Version 2.X Feature ABC

5 BRANCHING Branching ermöglicht parallele Entwicklung Jede Entwicklungstätigkeit (Bugfix, Feature, Stabilisation, usw.) bekommt Snapshot des Projekts Branching beinhaltet gewöhnlich: Snapshot der Sourcen für isoliertes Arbeiten Snapshot ist der Child Branch Ursprung oder Basis ist der Parent Branch Änderungen integrieren und stabilisieren Bi-Direktionale Synchronisation der Änderungen Merging Parent zu Child Integration Child zu Parent

6 MERGING Merging ist das Zusammenführen von Änderungen Merging zwischen Parent und Child ist Basefull Merging von Änderungen die nicht in einer Parent/Child Beziehung stehen ist Baseless Beim Base Full Merge-Vorgang kennt VSTS die Ursprungsdatei und kann Änderungen genau nachvollziehen (kennt 3 Dateien) Beim Base Less Merge Vorgang kennt VSTS nur die 2 zu mergenden Dateien und kann die spezifischen Änderungen nicht nachvollziehen.

7 ISOLATION IN VISUAL STUDIO TEAM SYSTEM Auf individueller Ebene: Workspaces Auf Teamebene: Branching Zwei oder mehr Child Branches Auf Datei, Verzeichnis oder Projektebene Es werden (virtuell) Kopien im TFS angelegt Die History bleibt erhalten Verfolgt werden Namensänderungen, Änderungen in Sourcefiles, neue und gelöschte Files,

8 BRANCHING MODELLE Dies sind die gebräuchlichsten Modelle: Branch by Branch by Purpose Mainline Model

9 BRANCH BY RELEASE QA Produktives Bug Fix 1.1 Dev QA Prod QA Produktives Merge Bug Fix Dev QA Prod Merge Bug Fix Dev

10 BRANCH BY RELEASE Einfachstes Branching Model Sobald ein für QA fertig ist kommt neuer Branch Alter Branch wird für Bugfixes und s genutzt Entwickler programmieren im neuen Branch Nachteile an diesem Ansatz: Bugfix in früherem Branch muss in allen nachfolgenden durchgereicht werden Ein Großteil der Personen muss bei jedem Branch wechseln nur ein kleiner Teil bleibt als QA Ausgecheckter Code muss in Ursprungs-Branch eingecheckt werden. Ein erneutes darf die nachträgliche Änderung nicht mit deployen.

11 BRANCH BY RELEASE CODE EINCHECKEN QA Bug Fix Produktives 1.1. Dev QA Prod Code muss wieder in 1.1 eingecheckt werden, gehört aber logisch zu 1.2. s von 1.1 dürfen den Code nicht enthalten 1.2 Dev

12 BRANCHING MODELLE Dies sind die gebräuchlichsten Modelle: Branch by Branch by Purpose Mainline Model

13 BRANCH BY PURPOSE Feature Freeze Bridge Bug Fixes Code Freeze Bugfix Merge-Vorgänge Main Dev Kandidat QA QA QA Alpha Beta Prod. Kandidat 1 Prod. Bugfix Produktives Prod. 1.0 Prod. 1.1

14 BRANCH BY PURPOSE Ein wird für bestimmten Zweck erstellt. Gewöhnlich für QA Systeme, Technology Previews, Unterstützt regelmäßige s und Emergency s Der Großteil der Personen bleibt im gleichen Branch Bugfixes werden in Main Branch zurück gemerged. Betrifft der Fehler neuere s wird er von Main dorthin gemerged. Ausgecheckter Code kann später wieder im Main Branch eingecheckt werden

15 BRANCH BY PURPOSE Feature Freeze Bug Fixes Code Freeze Main Kandidat Dev Alpha Beta Code kann nach dem Prod. Branch eingecheckt werden (bis dahin Shelving nutzen) Prod. Kandidat Produktives Prod. 1.0 Prod. 1.1

16 BRANCH BY PURPOSE FEATURE CREW Erweiterung um verstärkt parallele Entwicklung In Bereich Entwicklung werden neue Features in separaten Branches programmiert Der Main (Test/Integration) Bereich ist zur Codestabilisierung und Erzeugung von s Der Produktiv-Bereich ist für den Support releaster Produkte Entwicklung Feature Branch 1 Feature Branch Main Produktiv

17 BRANCH BY PURPOSE FEATURE CREW Feature 1 QA Build 2 Feature 2 Main ( 2) Bugfixes Mergen Feature 1 F 2 Produktiv

18 BRANCH BY PURPOSE FEATURE CREW In Main findet Stabilisation des Codes statt In Feature Branches findet eigentliche Entwicklung statt Feature Branches synchronisieren sich mit Main Vorgehen: Feature Branch synchronisiert vorab mit Main, eigentliche Integration findet so statt Fertiges Feature wird anschließend zu Main integriert Restliche Feature Branches synchronisieren sich mit Main. Das neue Feature wird dadurch dort integriert Die resultierende Integration in Main wird in den Produktiven Branch gemerged Einsatz: Entwickler arbeitet/en an Änderungen über Wochen Bei großen Anpassungen an der Systemarchitektur

19 BRANCHING MODELLE Dies sind die gebräuchlichsten Modelle: Branch by Branch by Purpose Mainline Model

20 MAINLINE MODEL Main Version 1.0 für QA Version 1.1 für QA Version 1.2 für QA Staging X Version 1.0 für Live X Version 1.1 für Live Version 1.2 für Live Live X X

21 MAINLINE MODEL Auch Website Model genannt (nur eine Version Produktiv) Es gibt insgesamt 3 Branches: Im Main Branch findet Entwicklung statt Der Staging Branch ist für QA und Stabilisation Live Branch für Live s/maintainance Die Branches werden für jedes recycled Vorgehen: copy up : Entwicklung -> Staging -> Live Bisherige Branch wird geleert und die neuen Sourcen dort hin kopiert. merge down : Live -> Staging -> Entwicklung Gefixte Bugs Nachteil: Alte s können schwerer gepacht werden

22 QUELLEN Microsoft Team Foundation Server Branching Guidance The Importance of Branching Models in SCM odels1.pdf Visual Studio Team System Workshop

23 Kontakt Frank Zehelein Teamleiter Software-Entwicklung VSTS-Consultant Telefon: