Projekte in der Krise III

Die Krux mit der Entwicklungsmaschine

Und wieder kommt ein neuer Stolperstein in das Projekt. Dieses mal handelt es sich gar nicht um die Projektmethodik selbst, sondern um ein viel banaleres und dennoch genauso ärgerliches Thema. Wir haben die Planung sauber durchgeführt, auch das Kick-Off war gut und jeder weiß was zu tun ist. Wir haben Qualitätsprozesse etabliert und sind nun bereit endlich den ersten Code zu schreiben! Wir gehen also zu unserem Entwicklungsteam und sagen, dass sie starten können. Und nun die Ernüchterung. Das Entwicklungsteam, dass wir ab heute voll eingeplant haben, und das ab heute auch unser Budget aufzehrt, kann nicht arbeiten! Wieso? Nun, wir haben für das Team keine Entwicklungsmaschinen.

Ja, aber! Das ist ja wohl Aufgabe des Entwicklers, dass er sein Handwerkszeug mitbringt! Schließlich habe ich ihm als Projektleiter ja auch keinen Laptop oder Tastatur besorgt! Schon, aber so einfach ist das nicht. Natürlich hat der Entwickler bereits für viele Kunden gearbeitet und natürlich hat er sich irgendwann auch mal eine Development-VM aufgesetzt. Doch die ist leider nicht das, was wir für unsere Anforderungen brauchen. Das kann dann sein, wenn wir z.B. mit einer ganz neuen Version von SharePoint arbeiten, für die es schlicht noch nichts gibt. Oder wir benötigen eine K2 oder Nintex Engine. Außerdem wurde diese Entwicklungsmaschine ja schon von 10 Projekten mit 1.000 Einzelanforderungen genutzt. Jede hat die Maschine etwas weiter kaputt konfiguriert und nun ist sie für uns einfach nicht mehr brauchbar.

Diese Problem mag einigen Projektleitern etwas weit hergeholt zu sein. Und tatsächlich tritt es auch nicht so häufig auf. Besonders in Zeiten des Client-Server-Object-Models ist es ehr selten, dass ein Projekt wirklich den ganzen Server kaputt konfiguriert. Doch auf der anderen Seite steht, dass der Schaden beträchtlich sein kann, wenn es wirklich auftritt. Spätestens bei Release-Wechsel der Host-Plattform (z.B. SharePoint) muss definitiv eine neue Maschine her. Im Idealfall haben wir tatsächlich eine Maschine pro Projekt und/oder Kunde, auf der wir den letzten Stand einfach archivieren können und wenn der Kunde eine Weiterentwicklung möchte, reaktivieren wir einfach die Maschine und arbeiten weiter. Meist ist dies aus Platzgründen Wunschdenken. Außerdem möchten die Projekte diese Konfiguration der Entwicklungs-VMs natürlich nicht zahlen. Also, was machen wir nun?

Die eleganteste Lösung bietet aus meiner Sicht die Azure Cloud an. Vor allem, wenn man selbst ein Entwickler mit MSDN-Subscription ist. Denn dann hat man auf der Azure Plattform bereits ein gewisses Cloud-Kontingent gratis dabei. Ja, schön. Aber ist das Problem dann jetzt nicht nur von meiner eigenen VM in eine Cloud-VM verschoben? Die Antwort ist nein. Denn Microsoft bietet inzwischen unzählige Images an, die verschiedenste Anforderungen abdecken. Im Rahmen dieses Artikels habe ich mir den aktuellsten Stand selbst einmal angesehen. Aktuell werden aktuell bereits Visual Studio 2017 RC und die SharePoint 2016 Trail Version als Konfigurationssetting für die eigene VM angeboten.

Ich habe der Vollständigkeit halber auch einmal getestet, wie lange die Installation der beiden Systeme dauert. Für Visual Studio hat es mich vom Einstellen der Parameter bis zur Eingabe der ersten Quellcode-Zeile etwa 30 Minuten gekostet. Das Öffnen von Visual Studio innerhalb der neuen VM hat beinahe genauso lange gedauert wie das Provisionieren der VM durch Azure. Aus meiner Sicht eine wirklich überzeugende Geschwindigkeit.

Für den SharePoint 2016 sah das Ganze ähnlich aus. 20 Minuten vom Konfigurieren bis zum Öffnen des Config Wizards. Insgesamt haben wir also innerhalb von etwa einer Stunde sowohl eine SharePoint 2016er Plattform als auch Visual Studio als Entwicklungsumgebung aufgesetzt und konnten anschließend arbeiten.

Wer übrigens eine vollständige Anleitung zum Installieren einer VM für SharePoint 2016 auf Azure benötigt, wird hier fündig: https://technet.microsoft.com/de-de/library/mt723354(v=office.16).aspx

Nachdem diese Maschinen übrigens einmal aufgesetzt wurden, kann man in den Einstellungen auch so genannte Automatisierungsskripte finden. Diese Skripte erlauben es einem exakt die gleiche Umgebung erneut aufzusetzen, indem man bspw. über PowerShell das Skript erneut ausführt. Das ist also dann interessant, wenn jemand zum Start eine blanke 2016er SharePoint VM mit Visual Studio 2015 R3 benötigt. Ein Skript absetzen und etwas warten. Dann wird in der eigenen Azure Umgebung eine neue Applikation provisioniert und kann anschließend eingesetzt werden.

Aber die Kosten! Ja, die sollte man nicht aus den Augen verlieren. Für eine virtuelle Maschine mit 8 Kernen und 14 GB RAM werden bei 160 Stunden Laufzeit (also 20 Tage * 8 Stunden) ca. 100€ fällig. Nimmt man einen separaten Domain Controller mit 2 Kernen und 4 GB RAM dazu ist man zusammen bei etwa 120€ pro Entwickler und Monat. Ein nicht unerheblicher Betrag. Doch man muss bedenken, dass einem Entwickler mit MSDN Lizenz ohnehin etwa 130 Euro Guthaben pro Monat zur Verfügung stehen. In diesem Fall würde er also nicht einen Euro echten Geldes kosten und hätte eine frische virtuelle Maschine für jedes Projekt, die auch nur dann das Guthaben belastet, wenn sie wirklich eingeschaltet ist.

Einzig die Staging-Maschinen sollten dann von einem Konto betrieben werden, dass nicht direkt den Entwicklern zugeordnet ist, um nicht die Budgetgrenzen zu sprengen. Oder man entscheidet sich dafür, dieses Geld zu investieren.

Und wenn man einen guten Sales Manager hat, dann verkauft dieser die entstehenden Kosten gleich mit. Immer mit dem Argument, dass die Entwicklungsmaschinen anschließend nicht gelöscht werden müssen und damit der letzte Entwicklungsstand sauber archiviert wird. Ein ziemlich guter Vorteil für Unternehmen im agilen Umfeld, wenn ihr mich fragt.

ALM Tech Blog

Application Lifecycle, Qualitäts- und Projekt-Management