© DrHitch/Shutterstock.com
TFS 2012 Versionskontrolle

6 Für Fortgeschrittene: Branch-Modelle


Die grundlegende Frage bei dem Umgang mit der Versionskontrolle ist die nach der Organisation des Codes und der übrigen Artefakte. Gleichzeitig haben diesbezügliche Entscheidungen eine große Tragweite, da sich einige Dinge später nur noch schwer ändern lassen. Daher ist es wichtig, die verbreiteten Modelle für die Codeorganisation zu kennen. Diese Betrachtungen sind konzeptioneller Natur, es ist also kein technisches Produktwissen erforderlich. Die nachfolgend geschilderten Strategien lassen sich auch in anderen Versionskontrollsystemen umsetzen.

Die Branch-Strategien, die hier vorgestellt werden, wurden von den ALM-Rangers in allgemeiner Form definiert und dokumentiert (Quelle: ALM Rangers). Die folgenden Ausführungen stützen sich auf diese Grundlagen.

6.1 Grundlagen

Codelinien

Die Gliederungseinheit für Artefakte in der Versionskontrolle ist die so genannte Codelinie, die zeitliche Betrachtung einer Menge von Dateien, die unter der Versionskontrolle stehen. Im einfachsten Fall existiert genau eine Codelinie, nämlich die, in der sich der Code befindet und in der dann auch die Weiterentwicklung und die Bugfixes vorgenommen werden (Abbildung 6.1).

34_BranchModellEineCodeLinie.png

Abbildung 6.1: Eine einzelne Codelinie

Zu Beginn der Nutzung des Versionskontrollsystems werden der vorhandene Code oder ein neues Projekt eingestellt. Im Laufe der Zeit wird dieser Codestand verändert, indem zum Beispiel neue Features implementiert werden (t=1 und t=2). Irgendwann ist dann die Zeit reif für ein Release, und die neue Software wird auf die Welt losgelassen (t=3). Doch damit ist die Entwicklung im Normalfall hoffentlich noch nicht zu Ende: Es gibt noch weitere Features, die implementiert werden wollen (t=4). Das kann auch mit dem Hinzufügen und Löschen von Dateien verbunden sein. Auch Bugs schleichen sich in die Software; sie wollen nachgestellt und beseitigt werden (t=5). Und schließlich wird es nicht bei einem Release bleiben, sondern es folgen weitere Releases der Software (t=6).

Schon der Abwicklung dieser einfach dargestellten Evolution einer Software wird man mit einer einzelnen Codelinie kaum gerecht. Solange es noch kein Release gibt, ist die Welt noch in Ordnung. Man kann parallel mit mehreren Entwicklern am Code arbeiten. Mit dem ersten Release fangen dann die Herausforderungen an: Der Kunde meldet einen Fehler, der zunächst einmal rekonstruiert werden muss. Allerdings ist in der Codelinie mittlerweile bereits einiges passiert, sodass intern der Codestand zu der Version des Kunden nicht ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang