Branch Policies in TFS2015 und Visual Studio Online

TFSlovesGitHeute bin ich auf der DWX – Developer Week 2015 und demonstriere das Zusammenspiel von GIT und TFS. Während meiner Vorbereitung ist mir aufgefallen, dass sich in den letzten Wochen viel getan hat und einige Neuerungen für GIT im TFS/VSO zu finden sind. Eine sehr spannende Erneuerung im Bereich Softwarequalität sind die sogenannten Branch Policies für Git Repositories.

In Zeiten von Continuous Delivery und schnellen Feedback-Schleifen ist ein funktionierender Source Code-Branch ein MUST HAVE. Um die Stabilität eines solchen Branches zu gewährleisten, sind verschiedene Qualitätsrichtlinien sinnvoll. Entwickler-Tests wie z.B. Unit-Tests setze ich hierbei voraus, ebenso wie die Verwendung von ausgewählten Entwicklungs-Branches. Spannend wird es aber dann, wenn man sich mit dem Merge-Prozess zwischen verschiedenen Entwicklungsständen beschäftigt.

Pull Requests

Für die Zusammenführung unterschiedlicher Source Code Stände gibt es im TFS oder Visual Studio Online seit geraumer Zeit die sogenannten Pull Requests.

Branch Policies PullRequestAbbildung 1: Pull Request von SampleBranch to Master

In einem Pull Request können Entwickler darum bitten, dass z.B. ihre Source Code Änderung aus ihrem Entwicklungs-Branch in einen Integrations-Branch aufgenommen wird. Der Request bietet die Möglichkeit, dass ein oder mehrere Reviewers benannt werden können, um sich den geänderten Code anzusehen. Die Idee ist, dass nur überprüfte und für gut befundene Änderungen in den Integrations-Branch übernommen werden können. Außerdem überprüft das System, ob eine Merge automatisch durchgeführt werden kann oder ob ein Konflikt besteht.

Branch Policies PullRequest WorkItemLink CommentsAbbildung 2: Pull Request mit Kommentar und ohne Merge-Konflikte

Branch Policies

Viele von Euch kennen vermutlichen den „Gated Check-In“-Mechanismus der Team Foundation Version Control, der zusätzliche Sicherheit bei der Integration von Source Code in einen bestimmten Branch bietet. Dieses Policy Gate gibt es in Git leider nicht, so dass man andere Methoden zur Qualitätssicherung verwenden muss. Die vorgestellten Pull Requests spielen dabei wieder ein zentrale Rolle. Mit der Version TFS 2015 (oder schon jetzt in Visual Studio Online) wird es eine Erweiterung geben, die sogenannten Branch Policies. Mit Hilfe dieser Branch Policies können für jeden Source Code-Branch Richtlinien hinterlegt werden. Die Einstellungsseite der Branch Policies befindet sich in der Projekt-Administration im Bereich der Version Control und wird für jeden Branch einzeln festgelegt (Team Projekt | Version Control | Repository | Branch).

Branch PoliciesAbbildung 3: Branch Policies Einstellungen in der Admin-Ansicht

In den Polcies kann beispielsweise ein automatischer Build ausgewählt werden, der den zu committenden Source Code überprüft und den Merge in den Branch gegebenenfalls verhindert, wenn das Ergebnis negativ ausfällt (Block the merge if the latest build did not succeed).

Eine kleine Einschränkung gibt es hier aber an dieser Stelle. Der Mechanismus funktioniert nur mit Build Definitionen der neuen Build Engine und nicht für XAML Builds.

Eine zweite Richtlinie sind Code Review Requirements. Mit Hilfe dieser Policy lässt sich festlegen, ob ein Code Review Voraussetzung für einen Pull Request ist und sogar wieviele Reviewers mindestens am Review-Prozess teilnehmen müssen.

Als Erweiterung der Code Review Requirements kann sogar festgelegt werden, dass einzelne Code Pfade von bestimmten Personen begutachtet werden.

Die Ergebnisse der eingestellten Richtlinien werden dann beim Durchführen eines Pull Requests im rechten oberen Bereich der Pull Request Ansicht dargestellt. In den nachfolgenden Abbildungen seht ihr einmal das Feedback für einen fehlgeschlagenen Build und einmal  das Feedback für die Verletzung der Reviewer-Regel.

Branch Policies PullRequest Build errorAbbildung 4: Pull Request mit fehlgeschlagenem Build

Branch Policies PullRequest ReviewersAbbildung 5: Pull Request mit Verstoß gegen Reviewer-Regel

Fazit

Die Neuerungen finde ich super und sind aus meiner Sicht auch dringend notwendig gewesen, um die Code-Qualität eines bestimmten Branches besser schützen zu können. Ich bin mir sicher, dass in Zukunft noch weitere Policies hinzukommen werden, um die Source Code-Qualität speziell in Git Repositories bestmöglich zu unterstützen.