Nachdem das Tooling beim Team Foundation Server 2012 sehr vielversprechend ist und mit reinen Git bzw. Mercurial-Mitteln zwar möglich, aber durchaus mit zusätzlichen Schritten für Entwicklern oder gar Kontextbrüchen einher geht, möchte ich mir dieses Thema genauer ansehen. Zwar gibt es durchaus Lösungen die eine gesamtheitliche Abbildung des Entwicklungsprozesses inkl. Einbindung von beispielsweise Scrum ermöglichen, allerdings sind die gefundenen Varianten kostenpflichtig, der TFS ist jedoch bereits In-Haus verfügbar, ohne Mehrkosten.
Visual Studio kann ja durch die Visual Studio Tools for Git recht passabel mit Git-Repositories arbeiten. Auch die Team Foundation Services (die “Cloud”-Variante des Team Foundation Servers) bietet die Möglichkeit der Git Team Projects. Innerhalb dieser Projekte wird mit Git-Repositories gearbeitet. Das bringt den Vorteil eines echten Distributed Version Control Systems (DVCS) mit den Templates des Team Foundation Servers zusammen. Soweit so gut. Das Ziel wäre jedoch der Einsatz der On-premise Variante. Hierzu gibt es viele Ankündigungen und Hinweise, dass ein Git-Support bald verfügbar wäre. Die Annahme, dass dies mit dem Update 2 nun endlich soweit ist, hat sich als falsch heraus gestellt. In einem Kommentar zu Visual Studio 2012 – Update 2 RTM musste ich erfahren, dass ein Git-Support kommen wird, jedoch erst im nächsten Major-Release. Also wohl nicht so schnell. Schade eigentlich.
Um für mich selbst ein Bild zu bekommen, ob die Services in Frage kommen (unabhängig der “Cloud”-Geschichte), warf ich einen Blick darauf. Auf meine Erkenntnisse möchte ich nachfolgend eingehen.
Pricing
Aktuell kann dieses Service kostenlos verwendet werden, Preise werden im Laufe 2013 veröffentlicht. Hierbei ist jedoch anzumerken, dass die Verwendung für MSDN Abonnenten wohl kostenlos bleiben dürfte (diesbezügliche Informationen finden sich hier). Derzeit läuft alles auf den Free Plan hinaus, der für bis zu 5 Benutzer verfügbar ist. Eine Verwendung mit mehr als 5 Benutzern ist möglich, wird aber nach Einführung von kostenpflichtigen Plänen (ohne MSDN Abonnement) wohl verrechnet werden. Die diesbezügliche Aussage auf der Webseite:
Just sign up for the Free Plan today and you can use the service for free. When we begin charging in 2013, access to the service will be offered as a benefit—at no additional charge—for paid MSDN subscribers at these levels:
- Visual Studio Ultimate with MSDN
- Visual Studio Premium with MSDN
- Visual Studio Test Professional with MSDN
You get all the benefits of your MSDN subscription plus you can store your work and collaborate with your project team in the cloud.
Wer also ein kleines Team oder ein MSDN-Abo hat, dürfte da auch zukünftig kein Problem haben. Zusätzliche Informationen über das Pricing habe ich nicht. Mal sehen was genau da noch kommen wird.
Test der Services
Für mich stellt sich nun die Frage, wie gut der Git-Support mit den Team Foundation Services wirklich funktioniert. Dazu sind die oben erwähnten Visual Studio Tools for Git notwendig und eine Anmeldung auf tfs.visualstudio.com.
Wenn erledigt hat man nun zwei Möglichkeiten:
Für mich ist die Variante mit Git-Unterstützung von Interesse.
Interessant ist hierbei, dass beide Schaltflächen die gleiche Funktionalität bieten, lediglich die Auswahl “Version control” entsprechend gesetzt wird. Projektname ausfüllen, das gewünschte Prozesstemplate wählen und anschließend per Create Project die Anlage starten.
Die Anlage dauert ein paar wenige Momente. Navigiert man im Anschluss zum Projekt wird man gleich mit den üblichen Scrum-Verdächtigen konfrontiert. Vorerst interessiert mich jedoch die Code-Verwaltung. Dazu ist auf den Menüpunkt CODE navigieren und man erhält die Clone-URL. Ein Wechsel zu Visual Studio steht also an.
Der Team Explorer bietet nun die Möglichkeit an, ein Git-Repository zu klonen. Wir holen uns also die entsprechende URL aus den Services und starten dies mal:
Im Zuge dieses Vorgangs wird ein Fenster zur Eingabe der Credentials geöffnet.
So erledigt, kann nun ein neues Projekt erstellt und im Clone-Folder abgelegt werden. Über den Team Explorer sind die Changes sofort ersichtlich. Per Kontextmenü können (und das ist auch notwendig) Dateien aus der Source Verwaltung exkludiert werden.
Hierbei ist mir aufgefallen, dass es mit den Visual Studio Tools for Git offensichtlich nicht möglich ist (oder ich habe es übersehen) eine .gitignore-Datei zu verwalten. Das könnte vielleicht ein wenig lästig sein. Deshalb habe ich mit TortoiseGit ein wenig nachgeholfen und eine entsprechende Datei angelegt, die darin gemachten Einträge werden – wie es aussieht – durch die Visual Studio Tools for Git berücksichtigt.
Edit: Eine .gitignore-Datei kann auch über den Team Explorer und der Git-Integration hinzugefügt werden. Dabei sind bei geöffnetem Repository die Git Settings zu öffnen. Danz unten unter Repository Settings kann ein entsprechendes File hinzugefügt werden.
Im nächsten Schritt folgen das erste Commit als auch ein Push, damit das Projekt im Remote-Repository verfügbar ist.
Ein Blick auf den Online-Zugang zeigt, es hat funktioniert:
Soweit der erste Test via Visual Studio. Zur Sicherheit möchte ich jedoch eine Änderung außerhalb machen und mit dem Git-Client meiner Wahl pushen.
Beim Push-Vorgang kommt nun ein Fehler – nach Eingabe der Credentials – der eigentlich auch nicht weiter verwundert, jedoch vielleicht ein wenig missverständlich ist:
Um dies zu beheben, muss man auf der Webseite zu den Team Foundation Services ins Benutzerprofil wechseln und unter Credentials alternative Daten angeben (bis dato wird ja lediglich mit einer Live ID gearbeitet):
Ein erneuter Push-Versuch resultiert in einem Erfolg:
Auch die weiteren Funktionen arbeiten ohne Probleme.
Fazit
Der erste Eindruck ist gut. Alles arbeitet gut zusammen, es gibt keine Hürden die unerwarteter Weise auftreten, es gibt auch nichts wo man großartig nachlesen müsste. Interessant wird es dann wenn es weiter geht in Richtung der Scrum-Templates und der Builds bzw. Testpläne etc. Aber dafür wird es eigenständige Blog-Beiträge geben, die näher darauf eingehen werden. Es ist sicherlich noch einiges zu tun, aber es lässt sich gut arbeiten, sowohl von Visual Studio heraus, als auch mit anderen Tools. Damit rückt der TFS definitiv wieder in die engere Wahl.