Software-Entwicklung und Application Lifecycle Management (ALM) mit Microsoft SharePoint 2010 und Visual Studio 2010

Transkript

1 Software-Entwicklung und Application Lifecycle Management (ALM) mit Microsoft SharePoint 2010 und Visual Studio 2010

2 Dieses Whitepaper bietet einen Einblick in die Möglichkeiten der durchgängigen und integrierten Software-Entwicklung mit Microsoft SharePoint 2010 und Microsoft Visual Studio Microsoft SharePoint wird in vielen Unternehmen als Plattform für Zusammenarbeit und Informationsaustausch genutzt. Gleichzeitig bietet SharePoint bereits seit der Version Microsoft Office SharePoint Server (MOSS) 2007 unzählige Möglichkeiten der Anpassung und Erweiterung wie.net Code, ASP.NET-Controls, WebParts, Site Templates und Content Types. So wird SharePoint schon heute in vielen Unternehmen als Applikationsplattform für individuelle Geschäftsanwendungen eingesetzt. Ausdruck der weiten Verbreitung ist die große SharePoint-Entwickler-Community, die inzwischen weltweit über Mitglieder hat. Microsoft SharePoint 2010 bietet im Vergleich zu MOSS 2007 viele Neuerungen, um benutzerdefinierte Anwendungen für SharePoint zu implementieren. Das neue Visual Studio 2010 und ein neues, in SharePoint integriertes Developer Dashboard machen die Entwicklung deutlich einfacher und produktiver. Aufgaben, die bislang nur mit sehr viel manueller Arbeit oder externen Tools durchgeführt werden konnten, werden durch visuelle Oberflächen und Werkzeuge in Visual Studio unterstützt. So integriert Visual Studio 2010 Projektvorlagen für Inhaltstypen, Funktionen, Listen- und Site-Definitionen, Workflows, visuelle WebParts sowie Assistenten für den Import bestehender Visual Studio-Projekte, SharePoint Solutions (WSP-Dateien) und SharePoint Designer-Workflows. Auch die Erstellung und Verteilung von SharePoint Solutions wird in Visual Studio besser unterstützt. Die Qualität einer unternehmensspezifischen Weiterentwicklung auf Basis von SharePoint als Applikationsplattform hängt in hohem Maße von transparenten und klar definierten Prozessen sowie einer reibungslosen Zusammenarbeit zwischen Mitgliedern innerhalb und außerhalb der beteiligten Entwicklungsteams ab. Hier kann Visual Studio 2010 Team Foundation Server helfen, eine effiziente und teamübergreifende Anwendungsentwicklung sicherzustellen. Gemeinsam mit Visual Studio 2010 bietet Team Foundation Server eine integrierte Anwendungsentwicklung mit einem zentralen Code-Repository, in dem sämtliche Prozessaktivitäten abgelegt werden, was ein durchgängiges Reporting ermöglicht. Dabei werden alle Rollen eines Software-Entwicklungsprojekts vom Projektleiter über den Architekten bis zum Entwickler und Tester durch ein offenes System optimal unterstützt. Zielgruppen des Whitepapers sind: Projektleiter, die mehr Transparenz und Sicherheit in die Planung und Überwachung von SharePoint-Projekten bekommen wollen IT-Leiter, deren Schwerpunkt auf der Bereitstellung und Qualitätssicherung von SharePoint-Erweiterungen liegt SharePoint-Entwickler, die mit Hilfe von Visual Studio die Entwicklung im Team beschleunigen möchten April 2010 Thomas Reimer, Microsoft Deutschland GmbH Šenaj Lelic, maguro DataAssist GmbH Sven Maier, Microsoft Deutschland GmbH Frank Maar, Microsoft Deutschland GmbH Torsten Mandelkow, Steria Mummert Consulting AG 2 Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio 2010

3 Inhaltsverzeichnis SharePoint 2010-Übersicht für den Entwickler... 4 Die Entwicklung von SharePoint-Lösungen umfasst mehrere Architekturebenen:... 4 Innovationen, Investitionen und Roadmap in SharePoint Kernkonzepte der Entwicklung mit SharePoint SharePoint und PowerShell... 5 Wichtigste Neuerungen in der Programmierung mit SharePoint Plattformunterstützung (64bit und.net Framework) 5 Ein neues User Interface (UI) auch für den Entwickler 5 Visual Studio 2010 Projektvorlagen und Projektstruktur... 6 Fehlerbehebung von Anfang an 6 SharePoint 2010 Tools in Visual Studio... 6 Developer Dashboard 7 LINQ to SharePoint 7 Business Connectivity Services 7 Client Object Model 8 Sandboxed Solutions 8 Claims-Based Authentication 8 Entwicklungsprozesse für SharePoint... 9 Besonderheiten der SharePoint-Entwicklung... 9 SharePoint 2007 (Büchse der Pandora) 9 SharePoint 2010 Entwicklungsmöglichkeiten hoch zwei 9 SharePoint-Entwicklungsprozess wozu? 9 SharePoint-Farmen nicht mehr kontrollierbar 9 SharePoint-Entwicklung bisher 10 Definierter SharePoint-Entwicklungsprozess...10 SharePoint Application Lifecycle Management...10 ALM mit Visual Studio Team System...10 Prozessvorlage...11 Anforderungsmanagement...11 Erfassung von Anforderungen in Visual Studio 11 Besonderheiten in der SharePoint-Entwicklung 11 Entwicklung...11 Neue Funktionen in Visual Studio 2010 für SharePoint 11 Erweiterbarkeit der Visual Studio-Plattform 11 Qualitätssicherung...12 Besonderheiten in der SharePoint-Entwicklung 12 Visual Studio Code-Analyse-Tools 12 Erweiterbarkeit der Code-Analyse 12 Testing...13 Funktionale Tests 13 Leistungstests 13 Regressionstests 13 Build Management...14 Zentraler Team Build 14 Deployment...14 SharePoint-Entwicklung im Jahr Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio

4 SharePoint 2010-Übersicht für den Entwickler SharePoint 2010 führt grundlegende Neuerungen für den Entwickler ein. War die Entwicklerunterstützung in SharePoint bislang stark durch separate Zusatzwerkzeuge (häufig auf Basis von Codeplex) geprägt, so führt SharePoint 2010 eine konsistente, durchgehende Unterstützung für den Entwickler ein. Damit werden die häufigsten Aufgaben und Probleme des Entwicklers moderner SharePoint-Lösungen angesprochen. SharePoint-Entwicklung im Kontext der Microsoft-Applikationsplattform SharePoint hat sich zu einer zentralen Komponente der Microsoft-Applikationsplattform entwickelt. So nutzen bereits viele andere Microsoft-Produkte und -Technologien SharePoint entweder als Lösungskomponente oder als Infrastrukturkomponente (ein bekanntes Beispiel ist Microsoft Project Server, das auf SharePoint basiert). Die Entwicklung von SharePoint-Lösungen umfasst mehrere Architekturebenen: Client: Client-Anwendungen erhalten die Möglichkeit, mit SharePoint-Komponenten Daten auszutauschen oder die Daten im SharePoint-System abzulegen (einfachstes Beispiel sind hier die Dokumentbibliotheken). Serveranpassungen: Serverseitige Lösungen stellen in der Regel eine anwendungsspezifische Erweiterung der SharePoint-Plattform für einen speziellen Zweck oder eine besondere Aufgabenstellung dar. Hierbei steht im Mittelpunkt, dass zwischen fertigen Lösungspaketen unterschieden werden kann (SharePoint 2007 führte das Konzept der Funktionen bereits als Grundkonzept ein) und es sich nicht um an spezifische Lösungen gebundene Erweiterungen der SharePoint-Plattform handelt (beispielsweise WebParts oder das Konzept der Shared Services). Interaktion mit externen Systemen und Daten: Diente SharePoint in den ersten Versionen primär als Collaboration-Plattform und Nachfolger von FileShares, hat sich der Funktionsumfang mittlerweile stark erweitert. Heutige SharePoint-Systeme stellen für den Anwender den zentralen Anlaufpunkt für den Zugriff auf beliebige Unternehmensdaten dar. Diese Daten liegen jedoch nicht zwingend in den Inhaltsdatenbanken der SharePoint- Farm, sondern häufig in externen Systemen und Datenquellen. Daher besteht in SharePoint 2010 über die Business Connectivity Services (BCS) die Möglichkeit, externe Daten, aber auch Geschäftsprozesse nahtlos zu integrieren. Innovationen, Investitionen und Roadmap in SharePoint 2010 Die wichtigsten Investitionen von Microsoft in SharePoint lassen sich für die Plattform 2010 in wenigen Stichworten zusammenfassen: Durchgängige Unterstützung für den Entwickler, von der Entwicklungsumgebung über die Fehlerbehebung bis hin zum Deployment von Lösungen. Flexible und skalierbare Erweiterbarkeit: SharePoint verfolgt in der Version 2010 mehr denn je ein Plattformkonzept und bietet Technologien und Komponenten, um Datenquellen transparent lesend und schreibend zu integrieren und die Plattform technologisch erweitern zu können. Zeitaufwändig waren bislang die häufigen Interaktionen zwischen Entwickler und Administrator, die teilweise unterschiedliche Anforderungen an die Plattform haben. Hier führt SharePoint 2010 eine klare Trennung und Vereinfachung für beide Seiten ein. Nutzbarkeit der Plattform: SharePoint als ursprünglich einfache Intranet-Collaboration-Lösung wurde über die Jahre immer weiter angereichert, wodurch die Bedienung immer komplexer wurde. Mit dem Umstieg auf das neue Fluent UI (vergleichbar mit Office 2007 und 2010) und eine Neustrukturierung der Oberfläche ist SharePoint sowohl für den Endanwender als auch für den Entwickler gleichermaßen leicht zu bedienen und zu erweitern. Kernkonzepte der Entwicklung mit SharePoint 2010 Die Entwicklung mit SharePoint 2010 bietet dem Entwickler erstmalig eine durchgehende Unterstützung. Auch mit SharePoint 2010 entstehen Lösungen durch Individualentwicklung unter Verwendung des SharePoint-Objektmodells. 4 Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio 2010

5 SharePoint 2010 bietet jedoch im Vergleich zu MOSS 2007 und Visual Studio 2008 die vollständige Einbindung der Entwicklungsaufgaben wie Fehlerbehebung und Deployment ohne Zuhilfenahme von Zusatzwerkzeugen. Die Basis für die Entwicklung ist dabei immer Visual Studio 2010 (SharePoint 2010 kann nicht mit früheren Versionen von Visual Studio erweitert werden), welches umfassende Projektvorlagen speziell für SharePoint 2010, wie Visual WebParts und EventReceiver, enthält. Das Client-Objektmodell ermöglicht außerdem den Fernzugriff auf SharePoint-Daten aus.net, Silverlight und ECMAScript. Eine wesentliche Herausforderung bei der Erstellung von SharePoint-Lösungen ist die Festlegung von Rollen für die Erstellung, Installation und Verwaltung. Um hier eine zusätzliche Abstraktions- und Isolationsebene bereitzustellen, ermöglicht SharePoint 2010 die Entwicklung von Lösungen, die in einem isolierten Bereich ablaufen (Sandbox). Sandboxed Solutions haben keinen Vollzugriff auf das serverseitige Objektmodell und können daher ohne Einbindung eines Farm- Administrators installiert werden. SharePoint und PowerShell PowerShell kann in SharePoint 2010 für verschiedene Automatisierungsaufgaben genutzt werden. Über PowerShell und die bereitgestellten SharePoint-SnapIn-Elemente kann der Entwickler leicht die Konfiguration einer SharePoint-Installation durchführen sowie Betriebsparameter setzen (wie Limits und Zeitfenster für komplexe Operationen und Anwendungen). PowerShell ersetzt das bisherige STSADM-Tool vollständig, was jedoch aus Gründen der Kompatibilität noch existiert. Wichtigste Neuerungen in der Programmierung mit SharePoint 2010 Im Folgenden werden einige der wichtigsten Neuerungen der SharePoint 2010-Entwicklungsplattform aufgeführt, um einen komprimierten Überblick zu geben. Plattformunterstützung (64bit und.net Framework) SharePoint 2010 steht nur noch als 64-Bit-Version zur Verfügung. Damit benötigt der Entwickler spätestens für SharePoint 2010 einen 64-Bit-Rechner beziehungsweise eine entsprechende Virtualisierungslösung. Eine 32-Bit-Version wird nicht mehr angeboten. War mit MOSS 2007 nur eine Installation auf einem Windows Server-Betriebssystem möglich, kann SharePoint 2010 auf einem 64-Bit-Client-Betriebssystem (Windows Vista oder Windows 7) installiert werden, was den Entwicklungsprozess stark vereinfach kann. Bei Projekten und Projektvorlagen ist Vorsicht geboten. Zum einen wird Visual Studio 2010 schon mit dem Microsoft.Net Framework 4.0 ausgeliefert SharePoint basiert jedoch auf dem.net Framework 3.5 so dass diese Auswahl bei den Projektvorlagen manuell umgestellt werden muss. Zum anderen ist die Voreinstellung der Projekte eine Kompilierung für die x86-plattform, was für SharePoint ungeeignet ist. Hier muss das Projekt manuell für den Build-Vorgang auf All Platforms oder x64 umgestellt werden, um problemlos kompilieren und Fehler beheben zu können. Ein neues User Interface (UI) auch für den Entwickler SharePoint 2010 führt serverseitig das aus den Office Client-Anwendungen seit der Version 2007 bekannte Fluent UI ein. Das Ribbon als zentrales Element des Fluent UI erleichtert und vereinheitlicht die Bedienung der SharePoint-Oberfläche und bietet sowohl dem Entwickler als auch dem Endanwender einen neuen, konsistenten Weg, um die SharePoint- Oberfläche zu bedienen und anzupassen. Zwar ist das Ribbon keine echte Entwicklerfunktion, jedoch ist auch für den Entwickler eine vereinfachte Bedienung der Oberfläche ein wichtiges Produktivitätskriterium. Das Ribbon kann vom Entwickler mit eigenen Funktionen angepasst und erweitert werden. Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio

6 Visual Studio 2010 Projektvorlagen und Projektstruktur Visual Studio Professional 2010 wird mit mehreren Vorlagen für SharePoint 2010 ausgeliefert. In der eigenen Gruppe für SharePoint 2010 finden sich für nahezu alle Aufgabenstellungen der SharePoint- Entwicklung entsprechende Projekt- und Elementvorlagen. Diese Vorlagen sind in eine neue Projektstruktur eingebettet, die eine einfache Entwicklung der SharePoint-Objekte ermöglicht. Abbildung: Projektvorlagen Fehlerbehebung von Anfang an Bereits beim Erstellen eines Projekts muss in Visual Studio 2010 ein Debug-Server hinterlegt werden, auf den das Projekt weitergegeben wird. Dabei werden die Deployment-Komponenten selbständig erzeugt und auf dem Server bereitgestellt. Ferner wird in der Projektvorlage auch der Typ der Anwendung (Farm oder Sandbox) erfasst auf die Unterschiede zwischen diesen Typen wird später eingegangen. Abbildung: Debug-Server-Abfrage Ist die Lösung vollständig, genügt dem Entwickler in Visual Studio 2010 ein Start im Debug-Modus. Damit verteilt Visual Studio die Lösung und bindet zugleich die Entwicklungsumgebung im Debug-Modus an den SharePoint-Arbeitsprozess, um eine Fehlerbehebung bei der programmierten Lösung zu ermöglichen. Somit unterscheidet sich die Art der Unterstützung für die Entwicklung und Fehlerbehebung durch Visual Studio 2010 für SharePoint nicht mehr von der klassischen Client-Entwicklung. SharePoint 2010 Tools in Visual Studio Zusätzlich sind in Visual Studio 2010 weitere SharePoint 2010 Tools enthalten, die eine Erleichterung für den Entwickler im Rahmen der Programmierung darstellen: Dedizierte SharePoint-Projektelementvorlagen SharePoint Explorer Projektablagestruktur Developer Dashboard Der SharePoint Explorer verwendet eine Baumstruktur, die analog zum Datenbank- Explorer als Unterkategorie des Solution Explorer bereitsteht und einen Drill-down in jede hinzugefügte SharePoint-Site, die zugrunde liegenden Listen sowie deren Daten ermöglicht. Der SharePoint Explorer ist eine rein lesende Erweiterung Schreibzugriffe auf SharePoint sind nicht möglich. 6 Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio 2010

7 Die Projektablagestruktur Ein SharePoint-Projekt besteht nicht nur aus den Code-Dateien für das zu programmierende Element und den üblichen Komponenten wie Eigenschaften und Verweisen in Visual Studio 2010 werden alle Komponenten automatisch hinzugefügt, die für das spätere Deployment wichtig sind: Funktionen, in denen die Komponenten verteilt werden Packages die nötigen Code-Dateien für die einzelnen Elemente Die komplette Weitergabe der Lösung ist somit über die Projektablagestruktur steuerbar bis hin zur exakten Definition und Automatisierung des Deployments. Eine zusätzliche Automatisierung kann beispielsweise die Aktivierung der Funktion nach der Installation beinhalten. Developer Dashboard In der Regel beginnt nach der erfolgreichen Entwicklung einer Lösung die Optimierung der Laufzeitumgebung. Hier stellt SharePoint 2010 dem Entwickler das neue Developer Dashboard zur Verfügung eine Oberfläche, mit der Entwickler und Administratoren zahlreiche Parameter und umfassende Informationen über das Laufzeitverhalten und mögliche Fehler erhalten. Zu den bereitgestellten Informationen gehören: Anzahl von Abfragen und deren Dauer Zeitaufwand für das Laden der Elemente oder/und Komponenten Zusätzlicher Zeitbedarf durch die Lösung LINQ to SharePoint Die Spracherweiterung LINQ (Language Integrated Query) wird nun auch für SharePoint-Daten implementiert. Zwar werden durch den LINQ-Provider für SharePoint immer noch CAML-Abfragen erstellt, der Entwickler kann sich jedoch vollständig auf die neue Programmierart mit der LINQ-Syntax konzentrieren. Dadurch ist eine deutlich verbesserte Fehlerbehebung möglich, da Fehler bereits zur Entwicklungszeit per IntelliSense aufgezeigt und so vermieden werden können. Als Tool wird hier SPMETAL ausgeliefert, das auf Kommandozeilenbasis dem Entwickler von Sites und Listen die Object-Wrapper erzeugt und als Code-Modul bereitstellt. Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio

8 Business Connectivity Services Die Einbindung externer Daten für den schreibenden und lesenden Vorgang war bislang in der Wahrnehmung vieler Entwickler recht kompliziert. In MOSS 2007 konnte hierfür der Business Data Catalog (BDC) verwendet werden, der jedoch aufwändig mit XML angepasst und programmiert werden musste. Der BDC stellte jedoch Daten innerhalb von SharePoint nur in lesender Form bereit ein schreibender Zugriff war nicht direkt möglich. Die neuen Business Connectivity Services und die neu definierbaren External Content Types sind die Nachfolgetechnologie des BDC. Die External Content Types können für einfachere Fälle auch ohne Code mit dem SharePoint Designer definiert und in die Oberfläche eingebunden werden, einschließlich der automatischen Erzeugung des nötigen Codes für CRUD-Operationen (Create-Read-Update- Delete) an der Grunddatenmenge. Für individuelle und nicht-standardkonforme Datenstrukturen besteht mit einer eigenen Projektvorlage sogar die Möglichkeit, eigene.net Assembly-Konnektoren zu entwickeln, die einen flexiblen programmatischen Weg des Datenaustauschs aus nahezu jeder beliebigen Quelle ermöglichen. Client Object Model Eine funktional reduzierte Version des Server-Objektmodells liegt dem SharePoint-Entwickler in Form einer auf Clients verteilbaren Bibliothek vor. Diese wird in drei Versionen ausgeliefert: NET Client OM Silverlight Client OM ECMA Script OM Alle drei Versionen erlauben das clientseitige Programmieren gegen das SharePoint-Objektmodell und stellen eine Untermenge der SharePoint API dar. In der Regel wurden die Objektnamen der SharePoint API beibehalten (üblicherweise wurde beim Typ das Präfix SP weggelassen, wie Web statt SPWeb ). Damit können nun Client-Anwendungen auch ohne Nutzung der SharePoint Web Services direkt mit SharePoint kommunizieren. Wichtig ist dabei zu erwähnen, dass im Gegensatz zum Server-Objektmodell beim Client die Abfragen immer explizit mit ExecuteQuery ausgelöst werden müssen das Client-Objektmodell optimiert hier die Netzwerklast und fragt Daten nicht durch bloße Erzeugung des Objekts sondern nur gegebenenfalls nach weiterer Einschränkung der Abfrage ab. Sandboxed Solutions In SharePoint 2007 war für eine Installation von Lösungen immer ein Farm-Administrator erforderlich. Für viele Szenarien war dies jedoch eigentlich nicht notwendig, da die Lösungen selten in den Sicherheitskontext eingriffen, etwa wenn neue WebParts die Oberfläche erweitern oder ergänzen sollten. Daher bietet SharePoint 2010 eine neue Art von Lösungen an. Die Technologie heißt Sandboxed Solutions und ermöglicht dem Farm-Administrator, dafür einige Grundregeln und Rahmenparameter zu definieren. Diese können dann vom Site-Administrator selbstständig installiert werden. Für die Lösungen kann eine spezialisierte Konfiguration der Laufzeitumgebung definiert werden. Darin kann auch festgehalten werden, welche Regeln die Anwendung befolgen muss. Dazu gehören Einstellungen, die die Ressourcennutzung oder das Fehlerverhalten von Anwendungen steuern. Die Sandboxed Solutions laufen unter einem anderen Sicherheitskontext als Farm-Lösungen und sind von ihren Zugriffsrechten her eingeschränkt. Daher sind ihre Entwicklung und ihr Deployment schnell und einfach zu bewerkstelligen. Die Installation kann sogar vom Site-Administrator beziehungsweise Site-Owner direkt vorgenommen werden, während sich der Entwickler auf die Entwicklung von Lösungen konzentrieren kann. Claims-Based Authentication Vor SharePoint 2010 gab es, abgesehen von der Authentifizierung über das Active Directory, keine komfortable Möglichkeit, andere Verzeichnisdienste oder Authentifizierungsquellen anzubinden. Mit der Claims-Based Authentication stellt SharePoint 2010 ein Modell bereit, mit dem nahezu beliebige Technologien für die Authentifizierung des Anwenders eingebunden werden können. Ein mögliches Szenario ist beispielsweise die Einbindung von Windows Live/Passport für das Login. Dadurch wird ermöglicht, dass sich Anwender innerhalb des Firmennetzwerks über das Active Directory authentifizieren. Greifen Anwender über das Internet auf den Server zu, erfolgt der Login bei gleichem URL über Windows Live. 8 Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio 2010

9 Entwicklungsprozesse für SharePoint Im zweiten Teil des Whitepapers wird gezeigt, wie die Entwicklung von SharePoint-Erweiterungen durch einen entsprechenden Entwicklungsprozess hinsichtlich Qualität und Transparenz verbessert werden kann. Der Schwerpunkt liegt dabei auf den Besonderheiten der SharePoint-Entwicklung im Vergleich zur klassischen Entwicklung in.net und darauf, inwiefern Visual Studio diese spezifisch unterstützen kann. Dabei wird auf eine generelle Beschreibung der Funktionalitäten von Visual Studio verzichtet und hierfür auf entsprechende weiterführende Referenzen verwiesen. Der Aufbau dieses zweiten Teils folgt den Prozessschritten eines Entwicklungsprozesses von der Anforderungsaufnahme über Entwicklung, Build, Test und Qualitätssicherung bis zum Deployment, analog zum klassischen Application Lifecycle Management (ALM). Genauso wie im allgemeinen ALM-Prozess geht es auch in der SharePoint-Entwicklung im Kern um folgende Ziele: Transparenz in Projekten durch Reports, Dashboards und Datawarehouses Automatisierung wichtiger Prozessschritte Nachvollziehbarkeit aller Prozesses Qualitätssteigerung und schnelle Umsetzung von Projekten Besonderheiten der SharePoint-Entwicklung SharePoint 2007 (Büchse der Pandora) Bereits bei MOSS 2007 hat sich gezeigt, dass die Erweiterbarkeit von SharePoint in vielen Unternehmen genutzt wird, um die Plattform den unternehmensspezifischen Anforderungen anzupassen. Die einfache Erweiterung durch WebParts, ContentTypes, Formularen und anderes war verlockend, um Anforderungen schnell und unkompliziert in SharePoint zu installieren. Microsoft SharePoint Designer hat dazu beigetragen, dass unternehmensspezifische Anforderungen sehr agil in SharePoint umgesetzt wurden. Viele SharePoint-Farmen wurden entsprechend unkontrolliert erweitert, so dass auf Basis von SharePoint teilweise sehr komplexe Anwendungen abseits der reinen Dokumentenverwaltung entwickelt wurden, etwa zur Verwaltung von Kundendaten, Schulungen und Lizenzen. SharePoint 2010 Entwicklungsmöglichkeiten hoch zwei Dieser Trend wird sich in Version 2010 noch verstärken, da die Zahl der Möglichkeiten für die im ersten Teil des Dokuments vorgestellten Erweiterungen von SharePoint nochmals gestiegen ist (etwa durch externe ContentTypes, Business Connectity Services oder Visio-Services). Dadurch wird sich SharePoint noch stärker als Plattform für die Anwendungsentwicklung etablieren, da hier viele wichtige Elemente einer typischen Anwendung bereits vorhanden sind: ein User Interface, Navigationselemente, Authentifizierung und Autorisierung, Anbindung von internen und externen Datenquellen, Formulare und anderes. Dies macht die Umsetzung von Anforderungen in Zukunft noch einfacher und schneller. SharePoint-Entwicklungsprozess wozu? Die vielfältigen Möglichkeiten, Anforderungen schnell und einfach umsetzen zu können, mögen einer der Gründe sein, warum das Thema SharePoint-Entwicklungsprozess in vielen Projekten bislang eine untergeordnete Rolle spielte. Anforderungen mussten schnell umgesetzt werden, es gab weder Zeit noch die Notwendigkeit für ein umfangreiches Projekt-Setup. Durch die häufig sehr detailreichen Lösungen (kleinere WebParts, einfache Workflows, Listendefinitionen) wurde der Aufwand für das Aufsetzen eines Entwicklungsprozesses mit entsprechender Tool-Unterstützung eher als Hindernis denn als Vorteil gesehen. SharePoint-Farmen nicht mehr kontrollierbar Aber das Fehlen eines Entwicklungsprozesses hat natürlich seine Nachteile: Die vielen detailreichen Entwicklungen wurden in der Summe über die Zeit häufig immer komplexer. Das rasante Wachstum der SharePoint-Farmen und die Menge der Erweiterungen lässt keine Nachvollziehbarkeit mehr zu: Wer hat wann welche Erweiterungen installiert? Wie wird die Erweiterung wieder deinstalliert? Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio

10 Welche Abhängigkeiten bestehen zwischen der Erweiterung und anderen Komponenten? Auf Basis welcher Anforderungen wurde eine bestimmte Erweiterung installiert? Welche Version einer Erweiterung ist wo in SharePoint installiert? Hinzu kommen die technischen Gegebenheiten von SharePoint. Erweiterungen sind häufig in der gesamten Farm verfügbar. Hier besteht die Gefahr von Konflikten und unerwarteten Quereffekten. Zusätzliche Probleme mit Abhängigkeiten, Versionsmanagement und Release-Management kommen hinzu. SharePoint-Entwicklung bisher Die folgenden Probleme sind anzusprechen: Die SharePoint-Entwicklung ist heute noch häufig von vielen Medienbrüchen und manuellen Schritten etwa beim Deployment, Testing oder der Entwicklung geprägt. Es herrscht wenig Transparenz in den SharePoint-Projekten, etwa bezüglich der Frage, welche Anforderung gerade wie umgesetzt wird. Die gewünschte Qualität der fertiggestellten Entwicklungen wird häufig wegen mangelnder Qualitätssicherungsprozesse im Projekt nicht erreicht. Konflikte zwischen den Erweiterungen können auftreten und werden häufig zu spät im Projekt erkannt und behoben. Wichtige Teile des Entwicklungsprozesses wie das Deployment werden nach hinten verschoben, und später auftretende Probleme verzögern den Projektfortschritt. Um diese Probleme in den Griff zu bekommen, ist der Entwicklungsprozess der wichtigste Ansatzpunkt, und dieser Entwicklungsprozess wird in SharePoint 2010 wichtiger denn je. Definierter SharePoint-Entwicklungsprozess Grundlage für erfolgreiche Entwicklungsprojekte ist der zugrunde liegende Prozess. Er definiert die Kommunikationswege, Rollen und Prozessschritte. Ein gelebter Entwicklungsprozess schafft Transparenz im Projekt und erhöht letztlich die Qualität der entwickelten Software. Dies ist bei SharePoint-Entwicklungsprojekten nicht anders. Die Entwicklung von SharePoint-Erweiterungen unterscheidet sich nicht generell von anderen Software-Entwicklungsprojekten. SharePoint Application Lifecycle Management Eine Basis zur Betrachtung des Entwicklungsprozesses bietet Application Lifecycle Management (ALM). ALM betrachtet die Entwicklung als permanent laufenden Prozess von Anforderung über die entsprechenden Phasen von Entwicklung, Test und Bereitstellung. Während des Betriebs einer Anwendung entstehen neue Anforderungen, die wieder in ihren Entwicklungsprozess einfließen. ALM bietet Vorgehensweisen, um diesen Prozess aktiv zu steuern und zu kontrollieren. Diese Vorgehensweisen können auch ideal im Bereich SharePoint-Entwicklung angewendet werden, da insbesondere in SharePoint Anwendungen entwickelt werden, die häufigen Änderungen und Verbesserungen unterliegen, die in kurzer zeitlicher Abfolge entwickelt werden müssen. ALM mit Visual Studio Team System Um einen Entwicklungsprozess für alle Teammitglieder zu unterstützen, ist eine Plattform erforderlich, die den Entwicklungsprozess komplett unterstützt. Visual Studio Team System unterstützt alle Phasen der Entwicklung, insbesondere auch für die SharePoint-Entwicklung, wie in den nachfolgenden Kapiteln gezeigt wird. 10 Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio 2010

11 Prozessvorlage Die Basis des Entwicklungsprozesses bildet immer ein definiertes Prozessmodell, etwa eher formale Prozessmodelle wie V-Modell oder agile Modelle wie SCRUM. Alle Teammitglieder arbeiten und kommunizieren nach dem gewählten Modell. In Visual Studio stehen bereits verschiedene Prozessvorlagen zur Verfügung. Diese Prozessvorlagen geben unter anderem entsprechende Rollen, Formulare, Vorlagen und Angaben zum Prozessstatus entsprechend dem gewählten Modell vor. Anforderungsmanagement Die strukturierte Erfassung von Anforderungen stellt sicher, dass diese korrekt umgesetzt werden und dies auch genau nachverfolgt werden kann. Während des gesamten Entwicklungsprozesses können so Informationen gewonnen werden, wie etwa: Welche Anforderungen wurden in welchem Release umgesetzt? Welche Komponente wurde entwickelt, um eine bestimmte Anforderung umzusetzen? Welche Tests wurden für eine Anforderung durchgeführt (Testabdeckung)? Erfassung von Anforderungen in Visual Studio Die Erfassung der Anforderungen erfolgt direkt in Visual Studio über entsprechende Formulare. Hierarchische WorkItems erlauben eine Strukturierung innerhalb der Anforderungen. Die Anforderungen können Entwicklern zugewiesen und somit jederzeit nachverfolgt werden. Später im Projekt wird durch die Erfassung in Visual Studio erkennbar, welche Anforderung in welchem Release installiert wurde oder welche Tests für eine Anforderung durchgeführt wurden. Besonderheiten in der SharePoint-Entwicklung Insbesondere bei der Entwicklung in SharePoint kommt dem Anforderungsmanagement eine enorm wichtige Bedeutung zu. Denn für jede Anforderung sind wichtige Fragen zu klären: Ist die Anforderung bereits durch eine Standardfunktion von SharePoint abgedeckt oder muss tatsächlich entwickelt werden? Make or Buy: Ist die Anforderung durch eine Drittanbieterkomponente bereits verfügbar? Doppelentwicklungen auf der Plattform vermeiden: Wurde die Anforderung bereits in ähnlicher Weise in einem früheren Projekt entwickelt? Eine entsprechende Prüfung dieser oder ähnlicher Fragen kann Kosten senken und die Qualität der Entwicklung verbessern. Entwicklung Trotz des Aufsetzens von SharePoint auf ASP.NET unterscheidet sich die Entwicklung in SharePoint stark von der Entwicklung reiner ASP.NET-Anwendungen. Zusätzliche SharePoint-spezifische Artefakt-Typen, wie Content Types, WebParts, Custom Actions, Features und Solutions, bieten Schnittstellen, um eigenen Code in SharePoint zu integrieren. Diese Entwicklungstypen haben jedoch auch ihre eigene Syntax sowie spezifische Möglichkeiten und Einschränkungen, die ein Entwickler kennen muss. Gleichzeitig muss er deren Nutzen, aber auch deren Einschränkungen für das eigene Projekt einschätzen können. Neue Funktionen in Visual Studio 2010 für SharePoint Die vielfältigen Funktionen in Visual Studio 2010 unterstützen den Entwicklungsprozess sehr viel besser als die vorherigen Produktversionen. Projekt- und Item-Vorlagen für SharePoint 2010 unterstützen den Entwickler bei häufig auftretenden Entwicklungsaufgaben (siehe erster Teil des Dokuments). Erweiterbarkeit der Visual Studio-Plattform Auch für die Entwicklung von SharePoint-Code ist die Erweiterbarkeit von Visual Studio Team System sehr hilfreich, da jedes Unternehmen eigene Entwicklungsrichtlinien verwendet. Die Erweiterungsmöglichkeiten der Entwicklungsumgebung Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio

12 sind vielfältig und wurden in Visual Studio 2010 nochmals erweitert. Die Entwicklungsumgebung kann angepasst werden, etwa durch eigene Projektvorlagen und Vorlagen für Entwicklungstypen Microsoft Domain Specific Languages für den grafischen Entwurf von Komponenten (DSL) Microsoft Guidance Automation Extensions zur Entwicklung von Software Factories (GAX/GAT) Microsoft Visual Studio Extensibility (VIX) Wichtig bei allen Erweiterungen ist die zentrale Bereitstellung für alle Entwickler, damit diese ein, abgestimmtes Vorgehen zur Code-Erzeugung wählen. Auch hier hat sich in VS 2010 durch die optimierten Möglichkeiten des Deployments von Erweiterungen (VIX) vieles verbessert. Qualitätssicherung Besonderheiten in der SharePoint-Entwicklung Mehr noch als bei anderen Entwicklungsprojekten ist hier eine hochwertige Qualitätssicherung notwendig, da mit SharePoint häufig verschiedenste Erweiterungen auf einer Plattform zusammenkommen. Neue Erweiterungen müssen vor ihrer Installation in der SharePoint-Farm ausgiebig geprüft werden. Ziele sind unter anderem: Konflikte mit anderen Erweiterungen vermeiden Sicherheit der Farm nicht gefährden Leistung der SharePoint-Farm nicht einschränken Für SharePoint-Projekte treffen generell die gleichen Qualitätskriterien zu wie für andere Entwicklungsprojekte: Stabilität, Erfüllung der Anforderungen, Leistung und so weiter. Zusätzlich kommen jedoch weitere Qualitätsindikatoren zum Tragen: Wie leicht lässt sich eine Anwendung auf eine neue Version aktualisieren (Upgradability)? Wie leicht lässt sich eine Anwendung auf eine neue Version von SharePoint heben (Migrateability)? Wie abhängig ist eine Komponente von anderen Komponenten und wird sie deshalb schwerer zu entfernen? Ist eine Komponente als Sandboxed Solution installierbar oder nicht? Solche Qualitätsindikatoren müssen gemessen und kontrolliert werden, um eine langfristige Nutzung und Stabilität zu gewährleisten. Visual Studio Code-Analyse-Tools Standardmäßig bietet Visual Studio verschiedene Tools zur Code-Analyse. Dazu gehören: FxCop zur Analyse von Code in Assemblies StyleCop zur Analyse von Quellcode SPDiposeChecker zur Überprüfung von SharePoint-Code auf potenzielle Speicherlecks Architekturbrowser zur Erkennung von Abhängigkeiten Code-Metriken zur Berechnung verschiedener Werte wie Lines of Codes oder zyklomatische Komplexität. Die Code-Analyse kann von Visual Studio in verschiedenen Stadien des Entwicklungsprozesses automatisch durchgeführt und somit erzwungen werden, wie etwa beim Check-In durch den Entwickler oder nach jedem Build. Erweiterbarkeit der Code-Analyse Eine individuelle SharePoint-Lösung besteht selten nur aus Assemblies sondern in der Regel auch aus diversen XML- Dateien, Images, CSS-Dateien, Dokumenten und anderen Komponenten, die nicht durch die Code-Analyse von Visual Studio analysiert werden können. Deshalb bietet Visual Studio sehr gute Möglichkeiten für die Erweiterung der Code- Analyse. An verschiedensten Stellen im Entwicklungsprozess können Tools von externen Anbietern an Quality Gates integriert werden, wie etwa eigene Check-In-Policies eigene Prüfregeln für die statische Code-Analyse mit FxCop eigene Prüfregeln für die Quellcode-Analyse mit StyleCop 12 Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio 2010

13 Testing In der Testing-Phase erfolgt die Prüfung der entwickelten Komponenten gemäß den Anforderungen. Häufig werden Tests von verschiedenen Mitgliedern im Projekt erstellt und von anderen Teams durchgeführt: Funktionale Tests: spezifiziert durch eine Fachabteilung, durchgeführt durch entsprechende Testteams. Unit-Tests: erstellt durch den Entwickler, automatisiert durchgeführt. Leistungstest: nicht-funktionale Anforderungen einer Fachabteilungen oder eines IT-Systembetriebs, Durchführung durch Testteams. Deshalb ist auch hier wieder die Arbeit aller Teammitglieder auf einer gemeinsamen Plattform wichtig, um eine möglichst hohe Transparenz und Nachvollziehbarkeit zu erreichen. Für alle oben genannten Bereiche bietet Visual Studio spätestens seit Version 2010 geeignete Tools. Funktionale Tests Funktionale Tests prüfen, ob die Anforderungen an die entwickelten Komponenten ausreichend erfüllt wurden. Diese Tests werden häufig durch dedizierte Testteams manuell anhand eines detaillierten Testplans durchgeführt. Für diese Art der Tests bietet Visual Studio in Version 2010 etwas wirklich Revolutionäres. So ist Visual Studio Test Professional 2010 eine integrierte Testmanagementlösung für Tester, Testmanager und Mitarbeiter in der Qualitätssicherung, die es vereinfacht, manuelle Tests und die automatische Fehlerdokumentation zu planen und durchzuführen. Dieses neue Werkzeug steht den Testern als separates Tool zur Verfügung, das nicht mehr in Visual Studio integriert ist, sondern eigenständig installiert und betrieben werden kann. Leistungstests Leistungstests werden häufig dazu verwendet, zu prüfen, wie sich die Leistung der Plattform durch die Installation einer Komponente verändert (Antwortzeiten, Speicherauslastung, Prozessorauslastung). Diese Tests sind in SharePoint besonders wichtig, da sich im Unterschied zu klassischen Plattformen viele Erweiterungen den Speicher und Prozessor teilen. Dies wurde in SharePoint 2010 jedoch durch Sandboxed Solutions für bestimmte Arten von Erweiterungen verbessert. Visual Studio Ultimate 2010 ermöglicht die umfassende Simulation einer realistischen Auslastung, um die Leistung von Webanwendungen unter allen denkbaren Bedingungen zu testen. Entwickler können so prüfen, ob ihre Lösungen fertig zur Auslieferung sind, und mögliche Probleme frühzeitig erkennen. Damit bietet Visual Studio im Bereich der Leistungstests sehr gute Möglichkeiten für SharePoint, die Nutzung zu simulieren. Zuvor werden mit Visual Studio Webtests aufgezeichnet, die das typische Verhalten eines SharePoint-Nutzers simulieren, wie etwa Dokumente hochladen, Dokumente bearbeiten, Listen erstellen, Seiten erstellen. Diese Webtests werden dann automatisiert mit Visual Studio durchgeführt, wobei dies parallel auf mehreren Rechnern und mit mehreren simulierten Benutzern erfolgen kann, um eine realistische Nutzung von SharePoint abzubilden. Während der Tests werden umfangreiche Kennzahlen aufgezeichnet, wie Auslastung von Speicher, Prozessor, Prozesse und Datenbankdurchsatz. Die gesammelten Informationen stehen in einem detaillierten Report zur Verfügung. Die standardisierten Webtests können so regelmäßig durchgeführt werden, um eine Leistungsveränderung in SharePoint zu erkennen. Regressionstests Durch die Verwendung einer gemeinsamen Plattform mit einer Vielzahl von Erweiterungen kommt den Regressionstests eine besondere Bedeutung zu. In Regressionstest wird geprüft, wie sich bereits vorhandene Erweiterungen durch die Veränderung einer Konfiguration oder Installation einer zusätzlichen Komponente verhalten. Auch dies kann Visual Studio durch die Möglichkeit zur Aufzeichnung von Webtests unterstützen. Standardisierte SharePoint-Tests, die parametrisierbar ausgeführt werden, können vor jeder größeren Konfigurationsänderung oder Installation neuer Komponenten Informationen darüber liefern, ob SharePoint noch wie erwartet funktioniert. Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio

14 Build Management Im Build Management geht es darum, den Quellcode der Mitglieder im Entwicklerteam zu kompilieren. Zentraler Team Build Durch das Fehlen einer zentralen Umgebung für die Kompilierung des SharePoint-Codes wird der Code häufig lokal bei einem einzelnen Teammitglied kompiliert und dann ausgeliefert. Jedoch ist der erfolgreiche Build einer SharePoint-Lösung stark abhängig von dem entsprechenden Konfigurationsstand des Zielsystems, wie vorhandene Servicepacks, vorhandene andere Packages oder Abhängigkeiten mit bereits installieren Paketen. Der erfolgreiche lokale Build auf dem Entwicklungsrechner, auf dem häufig die aktuellen Servicepacks, die neuesten Frameworks und Zusatztools installiert sind, lässt noch keine Aussage zu, ob der Code auch auf einer weniger gut ausgestatteten SharePoint-Farm reibungslos funktioniert. Dazu bietet Visual Studio den sogenannten Team Build, bei dem der Quellcode durch TFS kompiliert wird. Die Kompilierung erfolgt auf einem dedizierten Buildserver, dessen Konfiguration und installierte Komponenten denen des produktiven SharePoint-Systems entsprechen. Dadurch ist sichergestellt, dass der erfolgreich kompilierte Code in der Zielumgebung laufen kann. Deployment Im Gegensatz zu ASP.NET-Anwendungen oder anderen Software-Entwicklungsprojekten ist das Deployment in SharePoint meist sehr komplex. Der Installationsprozess besteht häufig nicht nur aus dem Installieren von Assemblies, dem Ausführen von DB-Skripts und dem Anlegen einer IIS-Seite. Fast immer sind während der Installation zusätzliche Schritte notwendig, etwa um eine neue Funktionalität in der bestehenden SharePoint-Umgebung zu aktivieren (wie die Aktivierung von Funktionen oder das Anpassen der Konfiguration). Dies kann in großen Umgebungen mit vielen bestehenden Sites unter Umständen sehr lange dauern. 14 Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio 2010

15 Zusätzlich sind während des Deployments häufig viele Parameter notwendig, wie URLs von bestehenden Sites, so dass ein Deployment parametrisierbar sein muss. Die Erfahrung aus aktuellen SharePoint-Projekten zeigt, dass die Komplexität des Deployments häufig unterschätzt wird. Das Deployment der Komponenten wird häufig zu spät im Projekt angegangen und getestet. Das Deployment wird nur auf Single-Server-Farmen getestet. Im Produktionsbetrieb sind jedoch häufig Farmen mit mehreren Frontends vorhanden, die einen hohen Einfluss auf ein erfolgreiches Deployment haben (etwa durch ein verzögertes Deployment). Häufig werden im Deployment viele manuelle Schritte eingeplant, die durch den IT-Administrator durchzuführen sind. Diese Schritte müssen dokumentiert werden, was zeitaufwändig ist. Die Durchführung der manuellen Installation ist ebenfalls zeitaufwändig und fehleranfällig. Häufig sind im Zielsystem viele Subsysteme involviert, deren Integration in MOSS frühzeitig geprüft werden muss (ISA- Server, Firewall, Kommunikationsstrecken und andere). Deshalb ist es wichtig, das Deployment frühzeitig im Projekt durchzuführen, sobald lauffähige Teilkomponenten zur Verfügung stehen, und das Deployment hochgradig zu automatisieren, damit ein wiederholbarer und testbarer Deployment-Prozess entsteht. Dazu stehen verschiedene Möglichkeiten zur Verfügung, zum Beispiel durch die Nutzung von PowerShell-Skripts oder der Skriptsprache Microsoft MSBuild. Ist ein Deployment-Prozess automatisiert durchführbar, kann Visual Studio diese Aufgabe in regelmäßigen Abständen übernehmen. Ein Szenario wäre zum Beispiel, nach jedem erfolgreichen Build den aktuellen Entwicklungsstand automatisch in einer Testfarm zu installieren und danach mit Webtests die Grundfunktionalitäten zu prüfen. Visual Studio protokolliert den gesamten Prozess von Build, Installation und Test und legt das Protokoll entsprechend ab. Dadurch wird eine höchstmögliche Transparenz im Projektfortschritt erreicht und Fehler in der Architektur oder im Deployment werden frühzeitig erkannt. SharePoint-Entwicklung im Jahr 2010 SharePoint-Entwicklungsprojekte unterscheiden sich im Kern nur wenig von typischen Softwareprojekten. Die Unterschiede liegen nur im Detail und sind aufgrund der Einschränkungen durch die Plattform gegeben (Deployment, Testbarkeit, Entwicklungsmöglichkeiten). Deshalb können die gleichen Prinzipien und Vorgehensweisen wie in der bewährten klassischen Software-Entwicklung angewendet werden. Mit Visual Studio 2010 stehen nun die Werkzeuge zur Verfügung, mit denen eine hochprofessionelle Entwicklung auch für SharePoint erfolgen kann. Das bisherige Vorgehen bei der SharePoint-Entwicklung, das ohne einen durchgängigen Entwicklungsprozess stattfand, gehört endgültig der Vergangenheit an. Weitere Informationen zu SharePoint 2010 und Visual Studio 2010 erhalten Sie online unter sharepoint.microsoft.com und Microsoft Corporation. Alle Rechte vorbehalten. Namen und Produkte anderer Firmen können eingetragene Warenzeichen der jeweiligen Rechteinhaber sein. Änderungen und Irrtum vorbehalten. Dieses Dokument dient ausschließlich Informationszwecken. MICROSOFT ÜBERNIMMT MIT DIESER ZUSAMMENFASSUNG KEINERLEI AUSDRÜCKLICHE ODER IMPLIZIERTE GEWÄHRLEISTUNG. Stand: April Whitepaper: Software-Entwicklung und ALM mit Microsoft SharePoint 2010 und Visual Studio

16