Seite 2: Stunde der Entwickler

Inhaltsverzeichnis

Die Stunde der Entwickler

Sind die Ideen und fachlichen Anforderungen in die Architektur gegossen, beginnt die Entwicklung. Der Programmierer erstellt nun Artefakte, und der Code soll natürlich mit Microsofts und Unternehmensvorgaben konform gehen und gleichzeitig von großer Qualität sein.

In Visual Studio 2008 musste der Entwickler für ein simples Artefakt wie ein Visual Web Part erst mal eine Fülle an Dateien und Strukturen manuell erzeugen. Microsoft hat in SharePoint 2010 und Visual Studio 2010 ein wenig nachgebessert und stellt mittlerweile Projekt- und Item-Templates für verschiedene Artefakte zur Verfügung. Leider bleiben dem Entwickler viele Aufgaben nach wie vor nicht erspart. Er muss viel XML tippen, eindeutige IDs von Standard-SharePoint-Bestandteilen wie Content Types, Features und Site Columns ermitteln, um für die korrekten Abhängigkeiten seines Codes zu sorgen. Zudem benötigt er oft detailliertes Wissen der "Innereien" von SharePoint.

Einfacherer Weg zum Code

Mit SPALM sollen Entwickler sich auch ohne diese tiefen Kenntnisse schnell in SharePoint zurechtfinden und Anwendungen implementieren können. Darüber hinaus soll es die Einstiegshürde für .NET-Entwickler senken, die sich bisher noch nicht mit SharePoint auseinandergesetzt haben und dennoch konform zu SharePoint-Standards entwickeln wollen.

Die kostenlose SharePoint Software Factory (SPSF) implementiert Microsofts seit Jahren unentgeltlich verfügbare Guidance Automation Extensions (GAX). Sie beschleunigt die Entwicklung von SharePoint-Code mit Wizards, Code-Generatoren, Templates, Code Snippets und integriert ihre Tools in Visual Studio. Sich häufig wiederholende Tasks wie lokales Deployment, Debugging, Erstellen von Web Solution Packages (WSPs) und De-/Aktivieren von Funktionen sind direkt aus Visual Studio heraus verfügbar.

Die Wizards führen den Entwickler beim Anlegen eines SharePoint-Projekts und beim Erstellen von Standardartefakten durch die einzelnen Schritte, fragen die erforderliche Informationen ab und generieren die Code-Fragmente in der SharePoint-Solution. Die Menüsteuerung zeigt dem Entwickler beispielsweise die Funktionen eines Content Type, und er wählt damit die Optionen aus, die er für die Applikation braucht. Das Ermitteln von IDs funktioniert über eine eingebaute Suche, die Dateien werden in Visual Studio erstellt und automatisch, entsprechend den Namenskonventionen, benannt.

SPSF ist kompatibel mit Visual Studio 2008 und 2010 und unterstützt in beiden Umgebungen SharePoint Server 2007 und 2010. Dennoch ist man nicht auf die Factory festgelegt, denn sie lässt sich jederzeit deaktivieren, wobei das Projekt funktionsfähig bleibt. Auch bestehende SharePoint-Projekte lassen sich um die Funktionen der Factory erweitern und werden bei der Migration von 2007 nach 2010 unterstützt.

Beim Kompilieren einer Applikation reicht es nicht, dass man eine Anwendung in Visual Studio baut, denn am Ende liegen alle Dateien als WSPs über die Ordner verstreut im Projekt. Besser ist es, wenn nach dem Kompilieren ein einziges installierbares Paket vorliegt, das sich versioniert ablegen lässt. Der Vorteil davon ist, dass ein anderer Entwickler sich das Set-up vom Zeitpunkt X nehmen und lokal auf seinem Rechner installieren kann, um dort einen Bug zu prüfen. Idealerweise sollte die Kompilierung im sogenannten Team-Build erfolgen, zum Beispiel mit TFS. Durch den Team-Build-Ansatz kompiliert man den Code auf Basis der produktiven SharePoint-Konfiguration und stellt sicher, dass am Ende die fertige Version produktiv geht und nicht die Debug-Version.

Qualitätskontrolle vor der Installation

SPALM ermöglicht durch die Standardisierung der Projekte eine leichtere Umsetzung und Wiederverwendung von Tests. Testvorlagen, zum Beispiel für Mocking-Frameworks, und Tools für das automatisierte Testen mit Visual Studio lassen sich ebenfalls in SPALM-Projekte integrieren.

Eine große Aufgabe stellen Unit-Tests dar. Für sie ist derzeit kein Standardvorgehen vorhanden, da der Test immer den Zugriff auf SharePoint braucht. Ziel ist aber, isoliert in Visual Studio zu testen. Ein Umweg ist das sogenannte Mocking, ein Verfahren, das eine SharePoint-Umgebung simuliert. Die Kosten und der höhere Einarbeitungsaufwand in die Mocking-Prozesse schrecken jedoch viele Entwickler ab.

Eine Unterstützung stellen immerhin das Aufnehmen der Web-, Performance- und Last-Tests und deren Ausführung mit Visual Studio dar. Jedoch wird ein großer Teil der Tests in SharePoint weiterhin manuell laufen. Mit dem neuen Test Center in Visual Studio 2010 vereinfacht sich das jedoch erheblich.