SharePoint-Entwicklung mit Application Lifecycle Management unterstützen

Seite 4: Fazit

Inhaltsverzeichnis

Der finale Schritt im ALM-Ansatz ist das Deployment, das Überführen des Softwarepakets in die SharePoint-Farm. Ziel ist es, auf dicke Installationshandbücher mit Anweisungen zum Durchklicken zu verzichten. Denn neben dem hohen manuellen Aufwand besteht das Risiko eines vergessenen Klicks. In dem Fall geht das große Suchen los. Liegt der Fehler im Paket oder beim Administrator? Die Fehlersuche erschwert zusätzlich, dass der Entwickler immer seltener auf den Integrations- oder Produktionsserver direkt zugreifen darf. Darüber hinaus kosten manuelle Deployments vor allem bei häufigen Änderungen und mehrstufigen Systemumgebungen viel Zeit und Geld, da der Administrator jedes Mal aufs Neue das Handbuch benötigt und "losklickt".

Sämtliche Schritte, Installation, Deinstallation und Aktualisierung einer Version sollten daher weitgehend automatisiert sein. Am besten ist es, der Projektleiter drückt nur auf Start, und die Version steht anschließend vollständig installiert und konfiguriert auf der Farm zum Testen bereit. Ideal wäre auch, wenn der Staging-Prozess, also der Durchlauf durch alle Farmen (Development, Test, Integration und Produktion), von selbst läuft. Wenige Unternehmen würden diese Automatisierung bis in die Produktions-Farm betreiben, aber die Stufen "Development", einer vorgeschalteten "Testfarm" sowie die "Integration" lassen sich sinnvoll automatisieren.

Das geht SPALM wie folgt an: Ein Projektleiter startet über TFS ein Deployment in die SharePoint-Umgebungen, auf der Build-Maschine entsteht das Paket und landet nach dem Bauen automatisch in der SharePoint-Farm. Von TFS aus startet man über ein Work Item den Task "Jetzt Installieren", woraufhin die Applikation in die Farm geladen wird. Dann wird eine Log-Datei geschrieben und an das Work Item für die spätere Prüfung angehängt. Auf der Development-Farm erhält der Projektleiter sofort grünes Licht für die Installation, auf allen anderen Stages erst, wenn der Code die richtige Qualität hat. Die prüfen definierte Quality Gates für einen Build- und Deployment-Prozess.

Voraussetzung für ein automatisiertes Deployment ist, ein sich selbst inklusive aller Parameter installierendes Paket zu erzeugen. Dafür hat sich MSBuild als Skriptsprache bewährt. Es gehört zu TFS und Visual Studio, ist auf jedem Rechner mit installiertem .NET Framework verfügbar und lässt sich gut parametrisieren und wiederverwenden. Allerdings enthält MSBuild durch seine XML-Basis schwer lesbaren Code. Alternativ lassen sich daher Batch-Dateien, VBScripts oder verstärkt im SharePoint-Umfeld nun auch PowerShell einsetzen.

SharePoint 2010 ist eine mächtige IT-Plattform, auf der zahlreiche, heute noch nicht absehbare Einsatzszenarien für die Softwareentwicklung entstehen werden. Damit erhöht sich allerdings der Bedarf einer geeigneten IT-Strategie. Bei der Betrachtung der heutigen SharePoint-Entwicklung gelangt man zu dem Eindruck, dass sie noch in der Kinderschuhen steckt. Aspekte wie automatisierte Tests, Code-Analyse, Code-Metriken, Continuous Integration, automatisiertes Deployment sind kaum im Einsatz und scheinen nur schwer umsetzbar. Das liegt zum einen an der fehlenden Tool-Unterstützung für die genannten Prozessschritte, zum anderen an den fehlenden Standards und Konventionen. Jedoch lassen sich mit relativ einfachen Mitteln diese Lücken füllen und damit eine SharePoint-Entwicklung professionell aufsetzen.

Ein auf SharePoint zugeschnittener Entwicklungsprozess à la SPALM kann dafür sorgen, eine SharePoint Entwicklung beherrschbar und effizient zu machen. Das steigert – was nicht unter den Tisch fallen soll – den Spaßfaktor beim Entwickeln.

Torsten Mandelkow und Matthias Einig
übernehmen als SharePoint-Architekten bei Steria Mummert Consulting seit mehreren Jahren die Entwicklung von SharePoint-Projekten. Ein aktueller Schwerpunkt ist zudem die Implementierung und Standardisierung von SharePoint-Entwicklungsprozessen in Unternehmen.

(ane)