War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Exportieren (0) Drucken
Alle erweitern
Erweitern Minimieren

Anwendungslebenszyklus-Verwaltung in SharePoint 2010

SharePoint 2010

Hier wird erklärt, wie Sie die Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM) in Microsoft SharePoint 2010-Projekten mithilfe von Microsoft Visual Studio 2010 und Microsoft SharePoint Designer 2010 planen und steuern. Außerdem erfahren Sie, welche Aspekte Sie beim Einrichten von Teamentwicklungsumgebungen, Entwickeln von Upgrade-Management-Prozessen und Erstellen eines Standard-SharePoint-Entwicklungsmodells berücksichtigen müssen.

Die Microsoft SharePoint 2010-Entwicklungsplattform, die Microsoft SharePoint Foundation 2010 und Microsoft SharePoint Server 2010 umfasst, enthält viele Funktionen, die Ihnen beim Entwickeln, Bereitstellung und Updaten von Anpassungen und benutzerdefinierten Funktionen für SharePoint-Websites helfen. Die Aufgaben, für die Sie diese Funktionen brauchen, fallen alle unter den Bereich Anwendungslebenzyklus-Verwaltung (Application Lifecycle Management, ALM).

Die wichtigsten Überlegungen beim Entwickeln von ALM-Prozessen betreffen nicht nur die Entwicklungs- und Testmethoden, die Sie vor der ersten Bereitstellung einer einzelnen Anpassung anwenden, sondern auch die Prozesse, die Sie zum Verwalten von Updates und Integrieren von Anpassungen und benutzerdefinierten Funktionen in einer vorhandenen Farm implementieren müssen. In diesem Artikel werden die Funktionen und Tools besprochen, die Sie beim Implementieren eines ALM-Prozesses in einer SharePoint-Farm nutzen können. Außerdem wird erklärt, welche besonderen Aspekte Sie beim Erstellen und Ausarbeiten eines ALM-Prozesses für die SharePoint-Entwicklung berücksichtigen müssen.

In diesem Artikel wird davon ausgegangen, dass jedes Entwicklungsteam einen individuellen ALM-Prozess entwickelt, der auf seine Größe und seine speziellen Anforderungen abgestimmt ist. Daher sind die Anleitungen zwangsläufig recht breit gefasst. Auf der anderen Seite müssen Sie unabhängig von der Größe Ihres Teams und der Natur Ihrer benutzerdefinierten Lösungen sicher ähnliche Überlegungen anstellen wie andere SharePoint-Entwickler auch, und Funktionen und Tools einsetzen, die für alle SharePoint-Entwickler relevant sind. Die Anleitungen in diesem Artikel helfen Ihnen, ein Entwicklungsmodell zu erstellen, das alle Vorzüge der SharePoint 2010-Plattform nutzt und gleichzeitig auf die individuellen Anforderungen Ihrer Organisation zugeschnitten ist.

Die Details Ihres SharePoint 2010-ALM-Prozesses werden zwar die individuellen Anforderungen Ihrer Organisation widerspiegeln, doch werden Sie die gleichen allgemeinen Schritte durchführen wie die meisten anderen Entwicklungsteams auch. Abbildung 1 zeigt ein Beispiel für einen ALM-Prozess für eine mittelgroße bis große SharePoint 2010-Bereitstellung. Der tatsächliche Prozess und die erforderlichen Aufgaben sind natürlich von der Projektgröße abhängig.

Abb. 1. Beispiel für einen ALM-Prozess

ALM-Beispielprozess

Im Folgenden werden die einzelnen Schritte des in Abbildung 1 gezeigten Prozesses aufgezählt (siehe entsprechende Beschriftungen 1 bis 10):

  1. Eine Person (z. B. ein Projektmanager oder leitender Entwickler) stellt die ersten Anforderungen zusammen und formuliert sie in Aufgaben um.

  2. Entwickler verwenden Microsoft Visual Studio Team Foundation Server 2010 oder andere Tools, um den Entwicklungsfortschritt zu dokumentieren und benutzerdefinierten Quellcode zu speichern.

  3. Da der Quellcode an einem zentralen Speicherort gespeichert wird, können Sie automatisierte Builds für Integrations- und Komponententests erstellen. Sie können die Testaktivitäten auch automatisieren, um die allgemeine Qualität der Anpassungen zu steigern.

  4. Nachdem die benutzerdefinierten Lösungen die Akzeptanztests erfolgreich durchlaufen haben, kann das Entwicklungsteam zur Vorproduktions- oder Qualitätssicherungsumgebung übergehen.

  5. Die Vorproduktionsumgebung sollte der Produktionsumgebung so weit wie möglich ähneln. Das bedeutet in der Regel, dass die Vorproduktionsumgebung die gleiche Patchebene und die gleichen Konfigurationen aufweist wie die Produktionsumgebung. Damit soll sichergestellt werden, dass die benutzerdefinierten Lösungen im Produktionsbetrieb einwandfrei funktionieren.

  6. Kopieren Sie gelegentlich die Produktionsdatenbank in die Vorproduktionsumgebung, um die Upgradeaktionen zu imitieren, die später in der Produktionsumgebung durchgeführt werden.

  7. Nach der Überprüfung in der Vorproduktionsumgebung werden die Anpassungen entweder direkt in der Produktionsumgebung oder zuerst in einer Stagingumgebung und dann in der Produktionsumgebung bereitgestellt.

  8. Nach der Bereitstellung in der Produktionsumgebung werden die Anpassungen mit der Produktionsdatenbank ausgeführt.

  9. Die Endbenutzer arbeiten in der Produktionsumgebung und geben Feedback und Anregungen zu den verschiedenen Funktionen. Probleme und Fehler werden gemeldet und mithilfe von festgelegten Prozessen verfolgt.

  10. Feedback, Fehler und andere Probleme in der Produktionsumgebung werden in Anforderungen übertragen, die wiederum priorisiert und dann in Aufgaben für Entwickler umgesetzt werden. Abbildung 2 zeigt, wie mehrere Entwicklerteams Fehlerberichte und Änderungsanforderungen bearbeiten können, die von den Endbenutzern der Produktionsumgebung gesendet wurden. Das Modell in Abbildung 2 veranschaulicht außerdem, wie die Entwicklungsteams ihre Lösungspakete koordinieren können. Beispielsweise arbeiten das Frameworkteam und das Funktionsentwicklungsteam nach separaten Versionsverwaltungsmodellen, die bei der Verfolgung von Fehlern und Änderungen jedoch aufeinander abgestimmt werden müssen.

    Abb. 2. Änderungsverwaltung für mehrere Entwicklerteams

    Änderungsverwaltung für mehrere Teams

Integrieren von Test- und Buildüberprüfungsumgebungen in einen SharePoint 2010-ALM-Prozess

In umfangreichen Projekten kann das Qualitätssicherungsteam (Quality Assurance, QA) eine zusätzliche Farm für Buildüberprüfungstests oder Benutzerakzeptanztests (user acceptance testing, UAT) nutzen, um die Builds in einer Umgebung zu testen, die der tatsächlichen Produktionsumgebung näher kommt. Eine Buildüberprüfungsfarm umfasst in der Regel mehrere Server, damit eine ordnungsgemäße Bereitstellung der benutzerdefinierten Lösungen sichergestellt ist. Abbildung 3 zeigt ein mögliches Modell für eine Kombination aus Integrations- und Testumgebungen, Buildüberprüfungsfarmen und Produktionsumgebungen. In diesem Modell werden die Vorproduktions- oder QA-Farm und die Produktionsfarm nach jeder Version miteinander ausgetauscht. Das hat den Vorteil, dass die Ausfallzeiten im Zusammenhang mit der Verwaltung der Umgebungen minimiert werden.

Abb. 3. Modell für zusammenhängende Integrations- und Testumgebungen

Modell für zusammenhängende Entwicklungsumgebungen

Integrieren von SharePoint Designer 2010 in einen SharePoint 2010-ALM-Prozess

Eine weitere wichtige Überlegung in Bezug auf die Anwendungslebenzyklus-Verwaltung betrifft Microsoft SharePoint Designer 2010. SharePoint 2010 ist eine hervorragende Plattform für codelose Lösungen, die mithilfe von SharePoint Designer 2010 erstellt und dann direkt in der Produktionsumgebung bereitgestellt werden können. Diese Anpassungen werden in der Inhaltsdatenbank gespeichert und nicht im Quellcoderepository. Allgemeine Designeraktivitäten und deren Zusammenwirken mit den Entwicklungsaktivitäten sind ein weiterer Aspekt, der zu berücksichtigen ist. Wollen Sie Seitenlayouts direkt in der Produktionsumgebung erstellen, oder wollen Sie sie als Teil der gepackten Lösungen bereitstellen? Beide Optionen haben ihre Vor- und Nachteile.

Welches Modell zur Anwendungslebenszyklus-Verwaltung Sie anwenden, hängt ganz von den benutzerdefinierten Lösungen und geplanten Anpassungen und nicht zuletzt von Ihren eigenen Vorgehensweisen ab. Ihr Prozess für die Anwendungslebenszyklus-Verwaltung muss nicht so komplex sein wie der in diesem Abschnitt beschriebene. Sie müssen jedoch schon in einer frühen Phase der Planung und Erstellung der Entwicklungsumgebung ein bindendes Modell festlegen, also weit vor dem Erstellen der benutzerdefinierten Lösungen.

Als Nächstes betrachten wir spezielle Tools und Funktionen im Zusammenhang mit der SharePoint 2010-Entwicklung, die Sie nutzen können, wenn Sie die Erstellung eines für Ihr Entwicklungsteam geeigneten Modells für die Anwendungslebenszyklus-Verwaltung mit SharePoint planen.

Ein großer Vorteil der SharePoint 2010-Entwicklungsplattform besteht darin, dass Sie damit Websites als Lösungspakete speichern können. Ein Lösungspaket ist ein bereitstellbares, wiederverwendbares Paket, das in einer CAB-Datei mit der Dateinamenerweiterung WSP gespeichert ist. Sie können ein Lösungspaket entweder mithilfe der SharePoint 2010-Benutzeroberfläche im Browser, mit SharePoint Designer 2010 oder mit Microsoft Visual Studio 2010 erstellen. Im Browser und in den SharePoint Designer 2010-Benutzeroberflächen werden Lösungspakete auch als Vorlagen bezeichnet. Dank dieser Flexibilität können Sie Websitestrukturen in einem Browser oder in SharePoint Designer 2010 erstellen und designen und diese Anpassungen dann zur weiteren Entwicklung in Visual Studio 2010 importieren. Dieser Vorgang wird in Abbildung 4 gezeigt.

Abb. 4. Ablauf über die SharePoint-Entwicklungstools

Ablauf über die SharePoint-Entwicklungstools

Sind die Anpassungen fertig gestellt, können Sie das Lösungspaket zur Verwendung in SharePoint bereitstellen. Nachdem Sie die vorhandene Websitestruktur mithilfe eines Browsers verändert haben, können Sie mit dem Zyklus von vorne beginnen, indem Sie die aktualisierte Website als Lösungspaket speichern.

Diese Interaktion zwischen den Tools ermöglicht auch den Einsatz weiterer Tools. Beispielsweise können Sie einen Workflowprozess in Microsoft Visio 2010 entwerfen und ihn in SharePoint Designer 2010 und anschließend von dort aus in Visual Studio 2010 importieren. Anleitungen zum Entwerfen und Importieren eines Workflowprozesses finden Sie unter Erstellen, Importieren und Exportieren von SharePoint-Workflows in Visio.

Weitere Informationen zum Erstellen von Lösungspaketen in SharePoint Designer 2010 finden Sie unter Speichern einer SharePoint-Website als Vorlage. Weitere Informationen zum Erstellen von Lösungspaketen in Visual Studio 2010 finden Sie unter Creating SharePoint Solution Packages.

SharePoint Designer 2010 unterscheidet sich von Microsoft Office SharePoint Designer 2007 dahin gehend, dass der Schwerpunkt statt auf Seiten mehr auf Features und Funktionen liegt. Die verbesserte Benutzeroberfläche bietet mehr Flexibilität beim Erstellen und Designen unterschiedlicher Funktionen. Mit den vielfältigen Tools lassen sich vollständige, wiederverwendbare und prozessorientierte Anwendungen erstellen. Weitere Informationen zu den neuen Funktionen und Features von SharePoint Designer 2010 finden Sie unter Erste Schritte mit SharePoint Designer.

Sie können SharePoint Designer 2010 auch verwenden, um modulare Komponenten zu verändern, die Sie mit Visual Studio 2010 erstellt haben. Beispielsweise können Sie Webparts und andere Steuerelemente in Visual Studio 2010 erstellen, in einer SharePoint-Farm bereitstellen und dann in SharePoint Designer 2010 bearbeiten.

Die primäre Zielgruppe für SharePoint Designer 2010 sind IT-Mitarbeiter und Information Worker, die mit dieser Anwendung Anpassungen in einer Produktionsumgebung erstellen. Daher müssen Sie für Ihre individuelle Umgebung ein Modell für die Anwendungslebenszyklus-Verwaltung (ALM) auswählen, das bestimmt, für welche Arten von Anpassungen der gesamte ALM-Entwicklungsprozess anzuwenden ist und welche Anpassungen mithilfe von SharePoint Designer 2010 durchgeführt werden können. Entwickler sind die sekundäre Zielgruppe. Sie können SharePoint Designer 2010 im Rahmen ihrer Entwicklungsaktivitäten einsetzen, besonders während der ersten Erstellung von Anpassungspaketen sowie für schnelle Entwicklung und schnelle Prototypenerstellung (Rapid Prototyping). Der ALM-Prozess muss außerdem definieren, wo und wie SharePoint Designer 2010 in das übergeordnetere Entwicklungsmodell eingebunden sein soll.

Eine der Herausforderungen von SharePoint Designer 2010 liegt in folgendem Punkt: Wenn Sie es zum Ändern von Dateien verwenden, werden alle Änderungen in der Inhaltsdatenbank gespeichert und nicht im Dateisystem. Wenn Sie beispielsweise eine Gestaltungsvorlage für eine bestimmte Website mithilfe von SharePoint Designer 2010 anpassen und dann neue Brandingelemente innerhalb eines Lösungspakets entwerfen und bereitstellen, stehen die Änderungen nicht für die Website mit der angepassten Gestaltungsvorlage zur Verfügung, weil diese Website die Version der Gestaltungsvorlage verwendet, die in der Inhaltsdatenbank gespeichert ist.

Damit solche Probleme weitestgehend vermieden werden, enthält SharePoint Designer 2010 neue Features, mit denen Sie die Nutzung von SharePoint Designer 2010 in einer bestimmten Umgebung steuern können. Sie können diese Steuereinstellungen auf der Webanwendungsebene oder auf der Ebene der Websitesammlung anwenden. Wenn Sie bestimmte Aktionen auf Webanwendungsebene deaktivieren, kann diese Einstellung auf der Ebene der Websitesammlung nicht geändert werden.

In SharePoint Designer 2010 sind die folgenden Einstellungen verfügbar:

  • Öffnen der Website in SharePoint Designer 2010 erlauben.

  • Anpassung von Dateien erlauben.

  • Anpassung von Gestaltungsvorlagen und Layoutseiten erlauben.

  • Websitesammlungsadministratoren das Anzeigen der URL-Struktur der Website erlauben.

Hinweis Hinweis

Diese Einstellungen werden ignoriert, wenn Sie das Farmadministratorkonto verwenden.

Da SharePoint Designer 2010 primär zur Anpassung von Inhalten in einer bestehenden Website dient, unterstützt es keine Quellcodeverwaltung. Standardmäßig werden Seiten, die Sie mithilfe von SharePoint Designer 2010 angepasst haben, in einer SharePoint-Bibliothek mit Versionsangabe gespeichert. Damit wird eine einfache Form der Versionsverwaltung unterstützt, aber keine umfassende Quellcodeverwaltung.

Wenn Sie eine Website im Browser als Lösungspaket speichern (über Website als Vorlage speichern auf der Seite Websiteeinstellungen), speichert SharePoint 2010 die Website als Lösungspaketdatei (WSP-Datei) und platziert sie im Lösungskatalog dieser Websitesammlung. Dann können Sie das Lösungspaket aus dem Lösungskatalog herunterladen und mithilfe der Vorlage SharePoint-Lösungspaket importieren in Visual Studio 2010 importieren, wie in Abbildung 5 gezeigt.

Abb. 5. Vorlage zum Importieren eines SharePoint Solution-Pakets

Vorlage zum Importieren eines SharePoint Solution-Pakets

SharePoint 2010-Lösungspakete enthalten zahlreiche Verbesserungen, in denen die neuen Funktionen genutzt werden, die in dem Featureframework zur Verfügung stehen. Die folgende Liste enthält einige der neuen Featureelemente, die Ihnen bei der Verwaltung Ihrer Entwicklungsprojekte und Upgrades helfen.

  • SourceVersion für WebFeature und SiteFeature

  • WebTemplate-Featureelement

  • PropertyBag-Featureelement

  • $ListId:Lists

  • WorkflowAssociation-Featureelement

  • CustomSchema-Attribut für ListInstance

  • Lösungsabhängigkeiten

Nach dem Importieren können Sie beginnen, Ihr Projekt beliebig anzupassen.

Hinweis Hinweis

Da diese Funktion auf dem WebTemplate-Featureelement beruht, das auf einer zugehörigen Websitedefinition basiert, enthält das sich ergebende Lösungspaket Definitionen für alle Elemente in der Seite. Weitere Informationen zum Erstellen und Verwenden von Webvorlagen finden Sie unter Webvorlagen.

Visual Studio 2010 unterstützt Quellcodeverwaltung (wie in Abbildung 6 gezeigt). Dadurch können Sie den Quellcode für Anpassungen an einem sichereren zentralen Speicherort speichern, und die Entwickler können Anpassungen problemlos untereinander austauschen.

Abb. 6. Quellcodeverwaltung in Visual Studio 2010

Visual Studio 2010-Quellcodesteuerelement

Auf welche Weise die Entwickler auf diesen Quellcode zugreifen und miteinander interagieren, hängt vom Aufbau der Teamentwicklungsumgebung ab. Im folgenden Abschnitt werden wichtige Überlegungen besprochen, die Sie beim Erstellen einer Teamentwicklungsumgebung für SharePoint 2010 berücksichtigen sollten.

Wie jeder ALM-Planungsprozess sollten auch Ihre Planungen für SharePoint 2010 folgende Schritte umfassen:

  1. Bestimmen und Erstellen eines Prozesses für die Initiierung von Projekten

  2. Festlegen und Implementieren eines Versionsverwaltungssystems für Quellcode und andere bereitgestellte Ressourcen

  3. Planen und Implementieren von Richtlinien für die Versionsverwaltung

  4. Bestimmen und Erstellen eines Prozesses für die Verfolgung und Meldung von Arbeitsaufgaben und Fehlern

  5. Verfassen der Dokumentation für die Anforderungen und Pläne

  6. Bestimmen und Erstellen eines Prozesses für automatisierte Builds und fortlaufende Integration

  7. Standardisieren des Entwicklungsmodells im Hinblick auf Wiederholbarkeit.

Microsoft Visual Studio Team Foundation Server 2010 (siehe Abbildung 7) stellt eine gute mögliche Plattform für viele dieser Elemente eines ALM-Modells dar.

Abb. 7. Visual Studio 2010 Team Foundation Server

Visual Studio 2010 Team Foundation Server

Nachdem Sie ein Modell für die Teamentwicklung festgelegt haben, müssen Sie zur Verwaltung der Entwicklung entweder eine Kombination aus Tools oder aber Microsoft Visual Studio Team Foundation Server 2010 auswählen. Microsoft Visual Studio Team Foundation Server 2010 bietet direkte Integration in Visual Studio 2010 und ermöglicht eine effiziente Steuerung des Entwicklungsprozesses. Es enthält zahlreiche Funktionen. Wie Sie es aber tatsächlich nutzen, hängt von Ihren Projekten ab.

Sie können Microsoft Visual Studio Team Foundation Server 2010 für folgende Aufgaben verwenden:

  • Verfolgen von Arbeitsaufgaben und Erstellen von Berichten über den Fortschritt der Entwicklung. Microsoft Visual Studio Team Foundation Server 2010 bietet Tools zum Erstellen und Ändern von Arbeitsaufgaben, die nicht nur von Visual Studio 2010, sondern auch vom Visual Studio 2010-Webclient bereitgestellt werden.

  • Speichern des gesamten Quellcodes für benutzerdefinierte Lösungen.

  • Protokollieren von Fehlern.

  • Erstellen, Ausführen und Verwalten von Tests mit umfassenden Testfunktionen.

  • Unterstützen der fortlaufenden Integration des Codes mithilfe der Funktionen für automatisierte Builds.

Microsoft Visual Studio Team Foundation Server 2010 bietet darüber hinaus eine Option für einfache Installation, mit der alle für Quellcodeverwaltung und automatisierte Builds benötigten Funktionen installiert werden. Dies sind in der Regel die am häufigsten verwendeten Funktionen in Microsoft Visual Studio Team Foundation Server 2010. Somit können Sie Ihre Entwicklungsumgebung mithilfe dieser Option schneller und einfacher einrichten.

SharePoint 2010 muss auf einem Entwicklungscomputer installiert sein, damit Sie das gesamte Potenzial dieser Entwicklungsfunktionen ausschöpfen können. Wenn Sie nur Remoteanwendungen entwickeln, z. B. Lösungen, in denen SharePoint-Webdienste, das Clientobjektmodell oder REST verwendet werden, könnten Sie Lösungen theoretisch auch auf einem Computer entwickeln, auf dem SharePoint 2010 nicht installiert ist. Allerdings würde dies die Produktivität Ihrer Entwickler beeinträchtigen, da diese dann die Vorzüge beim Debuggen nicht voll nutzen können, die zum Tragen kommen, wenn SharePoint 2010 direkt auf dem Entwicklungscomputer installiert ist.

Das Design der Entwicklungsumgebung hängt von der Größe und den Anforderungen des Entwicklungsteams ab. Auch die Wahl des Betriebssystems hat einen bedeutenden Einfluss auf das allgemeine Design des Teamentwicklungsprozesses. Es gibt im Wesentlichen die folgenden drei Optionen für das Erstellen von Entwicklungsumgebungen:

  1. Sie können SharePoint 2010 direkt unter dem Clientbetriebssystem des Computers ausführen. Diese Möglichkeit besteht nur, wenn Sie die 64-Bit-Version von Windows 7, Windows Vista Service Pack 1 oder Windows Vista Service Pack 2 verwenden.

  2. Sie können die Option zum Starten von virtueller Festplatte (Virtual Hard Drive, VHD) verwenden, d. h. Sie starten den Laptop durch Verwendung des Betriebssystems auf der virtuellen Festplatte. Diese Option ist nur verfügbar, wenn Sie Windows 7 als primäres Betriebssystem verwenden.

  3. Sie können Virtualisierungsfunktionen nutzen. Wenn Sie diese Option auswählen, haben Sie anschließend eine Vielzahl von Möglichkeiten. Aus betrieblicher Sicht ist die wahrscheinlich am einfachsten zu implementierende Option eine zentralisierte virtualisierte Umgebung, in der die individuelle Entwicklungsumgebung jedes Entwicklers gehostet wird.

Diese drei Optionen werden in den folgenden Abschnitten ausführlicher beschrieben.

SharePoint 2010 unter einem Clientbetriebssystem

Wenn Sie die 64-Bit-Version von Windows 7, Windows Vista Service Pack 1 oder Windows Vista Service Pack 2 verwenden, können Sie SharePoint Foundation 2010 oder SharePoint Server 2010 installieren. Weitere Informationen zum Installieren von SharePoint 2010 unter unterstützten Betriebssystemen finden Sie unter Einrichten der Entwicklungsumgebung für SharePoint 2010 unter Windows Vista, Windows 7 und Windows Server 2008.

Abbildung 8 zeigt, wie ein Computer, auf dem ein Clientbetriebssystem ausgeführt wird, in einer Teamentwicklungsumgebung funktionieren würde.

Abb. 8. Computer mit Clientbetriebssystem in einer Teamentwicklungsumgebung

Computer mit einem Clientbetriebssystem

Ein Vorteil dieser Vorgehensweise besteht darin, dass Sie das Potenzial jeder vorhandenen Hardware, auf der eines der zu verwendenden Clientbetriebssysteme ausgeführt wird, voll ausschöpfen können. Außerdem können Sie bereits vorhandene Konfigurationen, Domänen und Unternehmensressourcen nutzen, die in Ihrem Unternehmen unterstützt werden. Das hätte zur Folge, dass Sie wenig bis gar keine zusätzliche Unterstützung von der IT benötigen. Außerdem würden keine Zeitverzögerungen auftreten, wenn die Entwickler auf ihre Entwicklungsumgebungen zugreifen (wie das etwa beim Starten eines virtuellen Computers oder beim Herstellen einer Remoteverbindung zu der Umgebung der Fall wäre).

Allerdings müssen Sie bei diesem Ansatz sicherstellen, dass die Entwickler Zugriff auf ausreichende Hardwareressourcen haben. In jeder Entwicklungsumgebung sollten Sie einen Computer mit einer x64-fähigen CPU und mindestens 2 Gigabyte (GB) RAM für die Installation und Ausführung von SharePoint Foundation 2010 verwenden; 4 GB RAM sind im Hinblick auf die Leistung optimal. Für die Installation und Ausführung von SharePoint Server 2010 sollten Sie einen Computer mit 6 bis 8 GB RAM verwenden.

Ein Nachteil dieser Vorgehensweise liegt darin, dass die Umgebungen nicht zentral verwaltet werden und es schwierig ist, alle projektspezifischen Anforderungen in Bezug auf die Umgebungen synchron zu halten. U.u. ist es auch ratsam, Batchdateien zu schreiben, die einige der mit SharePoint zusammenhängenden Dienste starten und beenden. Dann beanspruchen diese Dienste, wenn die Entwickler nicht mit SharePoint 2010 arbeiten, keine Ressourcen und beeinträchtigen dann die Leistung der Computer nicht.

Durch das Fehlen einer zentralisierten Verwaltung könnte die Produktivität der Entwickler noch auf andere Weise beeinträchtigt werden. So könnte diese Vorgehensweise ungeeignet sein, wenn das Team an einem umfangreichen Microsoft SharePoint Online-Projekt arbeitet, in dem benutzerdefinierte Lösungen für viele Dienste entwickelt werden (z. B. die Entsprechungen zu http://intranet, http://mysite, http://teams, http://secure, http://search, http://partners und http://www.internet.com) und dann in mehreren Ländern oder Regionen bereitgestellt werden. Wenn Sie auf einem Computer entwickeln, auf dem ein Clientbetriebssystem in einer Unternehmensdomäne ausgeführt wird, hätte jeder Entwicklungscomputer einen eigenen Namen (und jede lokale Domäne einen anderen Namen, z. B. http://dev1 oder http://dev2). Wenn jeder Entwickler benutzerdefinierte Funktionen für mehrere Dienste implementiert, müssen Sie unterschiedliche Portnummern verwenden, um die einzelnen Dienste voneinander zu differenzieren (etwa http://dev1 für http://intranet und http://dev1:81 für http://mysite). Wenn alle Entwickler die gleichen Visual Studio 2010-Projekte verwenden, muss die URL zum Debuggen eines Projekts immer dann manuell geändert werden, wenn ein Entwickler die neueste Version eines Projekts aus dem Quellcoderepository entnimmt. Das macht eine manuelle Aktion erforderlich und schmälert somit die Produktivität der Entwickler. Außerdem würde es die Effizienz der Skripts beeinträchtigen, die Sie zum Einrichten von Entwicklungsumgebungen geschrieben haben, weil die einzelnen Umgebungen nicht standardisiert sind. Für umfangreiche Unternehmensentwicklungsprojekte ist daher Zentralisierung in einem gewissen Umfang bei der Virtualisierung zu empfehlen.

SharePoint 2010 unter Windows 7 und Starten von virtueller Festplatte

Wenn Sie Windows 7 verwenden, können Sie auch eine virtuelle Festplatte (Virtual Hard Drive, VHD) aus einem vorhandenen Windows Server 2008-Abbild erstellen, auf dem SharePoint 2010 in Windows Hyper-V installiert ist, und dann Windows 7 mit BDCEdit.exe so konfigurieren, dass es direkt im Betriebssystem auf der virtuellen Festplatte gestartet wird. Weitere Informationen zu dieser Konfiguration finden Sie unter Bereitstellen von Windows auf einer virtuellen Festplatte mit systemeigenem Start und Starten von einer virtuellen Festplatte in Windows 7.

Abbildung 9 zeigt, wie ein Computer, auf dem Windows 7 ausgeführt und der von einer virtuellen Festplatte gestartet wird, in einer Teamentwicklungsumgebung funktionieren würde.

Abb. 9. Windows 7 und Starten von einer virtuellen Festplatte in einer Teamumgebung

Windows 7 und Starten von einer virtuellen Festplatte in einer Teamumgebung

Ein Vorteil dieser Vorgehensweise ist die Flexibilität aufgrund der vielen dedizierten Umgebungen für ein einzelnes Projekt, durch die Sie jede Entwicklungsumgebung isolieren können. Dadurch verweisen die Entwickler in ihren Projekten nicht versehentlich auf Artefakte und sie können projektabhängige Umgebungen erstellen.

Allerdings bringt diese Option beträchtliche Hardwareanforderungen mit sich, da Sie die verfügbaren Hardwarekomponenten und Ressourcen direkt auf Ihren Computern verwenden.

SharePoint 2010 in zentralisierten virtualisierten Umgebungen

In einer zentralisierten virtualisierten Umgebung werden die Entwicklungsumgebungen an einem zentralen Speicherort gehostet, und die Entwickler greifen über Remoteverbindungen auf diese Umgebungen zu. Das bedeutet, Sie verwenden Windows Hyper-V an dem zentralen Speicherort und kopieren eine virtuelle Festplatte für jeden Entwickler, je nach Bedarf. Jede virtuelle Festplatte wird so konfiguriert, dass sie über das Unternehmensnetzwerk verfügbar ist, sodass nach dem Starten über Remoteverbindungen auf sie zugegriffen werden kann.

Abbildung 10 zeigt, wie eine zentralisierte virtualisierte Teamentwicklungsumgebung funktionieren würde.

Abb. 10. Zentralisierte virtualisierte Teamentwicklungsumgebung

Zentrale virtuelle Entwicklungsumgebung

Dieser Ansatz bietet den Vorteil, dass die Hardwareanforderungen für für die einzelnen Entwicklercomputer relativ gering sind, da die eigentliche Arbeit in einer zentralen Umgebung ausgeführt wird. Die Entwickler könnten sogar Computer mit 1 GB RAM als Clients verwenden und dann Remoteverbindungen zum zentralen Speicherort herstellen. Außerdem können Sie die Umgebungen bequem von einem zentralen Speicherort verwalten und bei Bedarf jederzeit anpassen.

Für den zentralisierten Host sind die Hardwareanforderungen beträchtlich, aber die Entwickler können diese Umgebungen problemlos starten und beenden. Dadurch können Sie die Hardware, die Sie den Entwicklungsumgebungen zugewiesen haben, effizienter nutzen. Darüber hinaus eignet sich diese Plattform für umfangreichere Testumgebungen für den benutzerdefinierten Code (z. B. für Farmen mit mehreren Servern).

Nachdem Sie die Teamentwicklungsumgebung eingerichtet haben, können Sie die zahlreichen Funktionen für Bereitstellung und Upgrades nutzen, die in dem neuen Modell zum Packen von Lösungen in SharePoint 2010 enthalten sind. In den folgenden Abschnitten wird beschrieben, wie Sie diese neuen Funktionen in Ihrem ALM-Modell verwenden können.

Das SharePoint 2010-Modell zum Packen von Lösungen bietet zahlreiche nützliche Features, die Ihnen beim Planen der Bereitstellung von benutzerdefinierten Lösungen und der Verwaltung des Upgradeprozesses helfen. Sie können Versionsverwaltung für Assemblys implementieren, indem Sie Bindungsumleitungen in der Konfigurationsdatei für die Webanwendung anwenden. Außerdem können Sie Versionsverwaltung für Ihre Featureupgrades implementieren und mit Featureupgradeaktionen die Änderungen verwalten, die in den vorhandenen Websites erforderlich sein werden, damit die Featureupgrades übernommen werden. Diese Upgradeaktionen können entweder deklarativ oder programmgesteuert behandelt werden.

Mit dem Featureupgrade-Abfrageobjektmodell können Sie Abfragen im Code erstellen, die in den vorhandenen Websites nach Features suchen, die geupgradet werden können. Mithilfe dieses Objektmodells können Sie relevante Informationen über alle Features und Featureversionen abrufen, die in den SharePoint 2010-Websites bereitgestellt sind. In der Lösungsmanifestdatei können Sie außerdem konfigurieren, welche Art der IIS-Wiederverwendung (Internet Information Services, IIS) während eines Lösungsupgrades ausgeführt werden soll.

In den folgenden Abschnitten werden diese Funktionen und deren Verwendung ausführlicher beschrieben.

Verwenden von "BindingRedirect" mit SharePoint 2010-Assemblys

Sie können das BindingRedirect-Featureelement der Konfigurationsdatei von Webanwendungen hinzufügen. Es ermöglicht eine Umleitung von früheren Versionen installierter Assemblys zu neueren Versionen. Abbildung 11 zeigt, wie SharePoint durch die XML-Konfiguration aus der Lösungsmanifestdatei angewiesen wird, der Konfigurationsdatei für Webanwendungen Bindungsumleitungsregeln hinzuzufügen. Durch diese Regeln werden alle Verweise auf Version 1.0 der Assembly zu Version 2.0 weitergeleitet. Das ist in der Lösungsmanifestdatei notwendig, wenn Sie eine benutzerdefinierte Lösung upgraden, für die Assemblyversionsverwaltung implementiert ist, und wenn Instanzen der Lösung und der Assembly auf den Websites vorhanden sind.

Abb. 11. Bindungsumleitungsregeln in einer Lösungsmanifestdatei

Verbindliche Umleitungsregeln in einem Lösungsmanifest

Die Verwendung von Assemblyversionsverwaltung ist eine bewährte Methode, weil damit die Versionen einer Lösung, die in den Produktionsumgebungen bereitgestellt werden, auf einfache Weise verfolgt werden können.

Featureversionsverwaltung in SharePoint 2010

Dank der Unterstützung der Featureversionsverwaltung in SharePoint 2010 stehen Ihnen zahlreiche Funktionen zur Verfügung, die Sie beim Upgraden von Features nutzen können. Beispielsweise können Sie mithilfe der SPFeature.Version-Eigenschaft feststellen, welche Versionen eines Features in einer Farm bereitgestellt sind und welche folglich geupgradet werden müssen. Ein Codebeispiel, in dem dies veranschaulicht wird, finden Sie unter Version.

Durch die Featureversionsverwaltung in SharePoint 2010 können Sie außerdem einen Wert für die SPFeatureDependency.MinimumVersion-Eigenschaft zur Behandlung von Featureabhängigkeiten definieren. Beispielsweise können Sie die MinimumVersion-Eigenschaft verwenden, um sicherzustellen, dass eine bestimmte Version eines abhängigen Features aktiviert ist. Featureabhängigkeiten können in jeder neuen Version eines Features hinzugefügt oder entfernt werden.

Im SharePoint 2010-Featureframework wurde zudem das Objektmodell dahin gehend erweitert, dass es Featureversionsverwaltung besser unterstützt. Sie können die QueryFeatures-Methode verwenden, um eine Liste der Features abzurufen, und Sie können sowohl die Featureversion angeben als auch, ob ein Feature geupgradet werden muss. Die QueryFeatures-Methode gibt eine Instanz von SPFeatureQueryResultCollection zurück, mit der Sie auf alle Features zugreifen können, die aktualisiert werden müssen. Diese Methode ist in mehreren Bereichen verfügbar, da sie über die SPWebService-, SPWebApplication-, SPContentDatabase- und SPSite-Klasse verfügbar gemacht wird. Weitere Informationen zu dieser überladenen Methode finden Sie unter QueryFeatures(), QueryFeatures(), QueryFeatures() und QueryFeatures(). Eine Übersicht über das Featureupgrade-Objektmodell finden Sie unter Featureupgrade-Objektmodell.

Der folgende Abschnitt bietet einen Überblick über viele der neuen Upgradeaktionen, die Sie beim Upgraden von einer Version eines Features auf eine andere anwenden können.

Featureupgradeaktionen in SharePoint 2010

Upgradeaktionen werden in der Datei Feature.xml definiert. Die SPFeatureReceiver-Klasse enthält eine FeatureUpgrading-Methode, mit der Sie die während eines Upgrades auszuführenden Aktionen definieren können. Diese Methode wird während des Featureupgrades aufgerufen, wenn die Datei Feature.xml des Features ein oder mehrere <CustomUpgradeAction>-Tags enthält, wie im folgenden Beispiel gezeigt.

<UpgradeActions>
  <CustomUpgradeAction Name="text">
    ...
  </CustomUpgradeAction>
</UpgradeActions>

Jede benutzerdefinierte Upgradeaktion hat einen Namen, anhand dessen der im Featureempfänger auszuführende Code differenziert werden kann. Wie im folgenden Beispiel gezeigt, können Sie Instanzen von benutzerdefinierten Aktionen parametrisieren.

<Feature xmlns="http://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange EndVersion ="2.0.0.0">
      <!-- First action-->
      <CustomUpgradeAction Name="example">
        <Parameters>
          <Parameter Name="parameter1">Whatever</Parameter>
          <Parameter Name="anotherparameter">Something meaningful</Parameter>
          <Parameter Name="thirdparameter">additional configurations</Parameter>
        </Parameters>
      </CustomUpgradeAction>
      <!-- Second action-->
      <CustomUpgradeAction Name="SecondAction">
        <Parameters>
          <Parameter Name="SomeParameter1">Value</Parameter>
          <Parameter Name="SomeParameter2">Value2</Parameter>
          <Parameter Name="SomeParameter3">Value3</Parameter>
        </Parameters>
      </CustomUpgradeAction>
    </VersionRange>
  </UpgradeActions>
</Feature>

Dieses Beispiel enthält zwei CustomUpgradeAction-Elemente, eines mit dem Namen example und ein anderes namens SecondAction. Beide Elemente haben unterschiedliche Parameter, die von dem Code abhängen, den Sie für den FeatureUpgrading-Ereignisempfänger geschrieben haben. Im folgenden Beispiel sehen Sie, wie Sie diese Upgradeaktionen und ihre Parameter in Ihrem Code verwenden können.

/// <summary>
/// Called when feature instance is upgraded for each of the custom upgrade actions in the Feature.xml file.
/// </summary>
/// <param name="properties">Feature receiver properties</param>
/// <param name="upgradeActionName">Upgrade action name</param>
/// <param name="parameters">Custom upgrade action parameters</param>

public override void FeatureUpgrading(SPFeatureReceiverProperties properties, 
                                        string upgradeActionName, 
                                        System.Collections.Generic.IDictionary<string, string> parameters)
{

    // Do not do anything, if feature scope is not correct.
    if (properties.Feature.Parent is SPWeb)
    {

        // Log that feature scope is incorrect.
        return;
    }

    switch (upgradeActionName)
    {
        case "example":
            FeatureUpgradeManager.UpgradeAction1(parameters["parameter1"], parameters["AnotherParameter"],
                                                 parameters["ThirdParameter"]);
            break;
        case "SecondAction":
            FeatureUpgradeManager.UpgradeAction1(parameters["SomeParameter1"], parameters["SomeParameter2"],
                                                 parameters["SomeParameter3"]);
            break;
        default:

            // Log that code for action does not exist.
            break;
    }
}

Sie können beliebig viele Upgradeaktionen verwenden und sie auf Versionsbereiche anwenden. Im folgenden Beispiel wird gezeigt, wie Sie Upgradeaktionen auf Versionsbereiche eines Features anwenden können.

<Feature xmlns="http://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange BeginVersion="1.0.0.0" EndVersion ="2.0.0.0">
      ...
    </VersionRange>
    <VersionRange BeginVersion="2.0.0.1" EndVersion="3.0.0.0">
      ...
    </VersionRange>
    <VersionRange BeginVersion="3.0.0.1" EndVersion="4.0.0.0">
      ...
    </VersionRange>
  </UpgradeActions>
</Feature>

Mit der AddContentTypeField-Upgradeaktion können Sie zusätzliche Felder für einen vorhandenen Inhaltstyp definieren. Diese Aktion bietet außerdem die Möglichkeit, die Änderungen per Pushdown an untergeordnete Instanzen zu verteilen, was meistens das bevorzugte Verhalten ist. Bei der ersten Bereitstellung eines Inhaltstyps in einer Websitesammlung wird eine Definition dafür auf der Ebene der Websitesammlung erstellt. Wird dieser Inhaltstyp dann in einer Unterwebsite oder Liste verwenden, so wird eine untergeordnete Instanz des Inhaltstyps erstellt. Damit sichergestellt ist, dass jede Instanz des betreffenden Inhaltstyps aktualisiert wird, müssen Sie das PushDown-Attribut auf true festlegen, wie im folgenden Beispiel gezeigt.

<Feature xmlns="http://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange EndVersion ="2.0.0.0">
      <AddContentTypeField ContentTypeId="0x0101002b0e208ace0a4b7e83e706b19f32cab9"
                           FieldId="{ccbcd479-94c9-4f3a-95c4-58897da434fe}"
                           PushDown="True"/>
    </VersionRange>
  </UpgradeActions>
</Feature>

Weitere Informationen zur programmgesteuerten Verwendung von Inhaltstypen finden Sie unter Einführung zu Inhaltstypen.

Mit der ApplyFeatureManifests-Upgradeaktion können Sie neue Artefakte auf eine SharePoint 2010-Website anwenden, ohne Features erneut zu aktivieren. So, wie Sie einer beliebigen neuen elements.xml-Datei in SharePoint neue Elemente hinzufügen können, können Sie SharePoint auch anweisen, Inhalte aus einer bestimmten Elementdatei auf Websites anzuwenden, in denen ein bestimmtes Feature aktiviert ist.

Diese Upgradeaktion können Sie verwenden, wenn Sie ein vorhandenes Feature upgraden, dessen FeatureActivating-Ereignisempfänger Aktionen ausführt, die auf Websites, auf denen das Feature bereitgestellt wird, nicht noch einmal ausgeführt werden sollen. Im folgenden Beispiel wird veranschaulicht, wie Sie diese Upgradeaktion in eine Feature.xml-Datei integrieren können.

<Feature xmlns="http://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange EndVersion ="2.0.0.0">
      <ApplyElementManifests>
        <ElementManifest Location="AdditionalV2Fields\Elements.xml"/>
      </ApplyElementManifests>
    </VersionRange>
  </UpgradeActions>
</Feature>

Ein Beispiel für einen Anwendungsfall für diese Upgradeaktion ist das Hinzufügen von neuen WEBPART-Dateien zu einem Feature in einer Websitesammlung. Mithilfe der ApplyElementManifest-Upgradeaktion können Sie diese Dateien hinzufügen, ohne das Feature erneut zu aktivieren. Ein weiteres Beispiel sind Seitenlayouts, die erste Webpart-Instanzen enthalten, die in der Dateielementstruktur der Featureelementdatei definiert sind. Wenn Sie dieses Feature erneut aktivieren, erhalten Sie Duplikate dieser Webparts in jedem Seitenlayout. In diesem Fall können Sie mithilfe des ElementManifest-Elements der ApplyFeatureManifests-Upgradeaktion neue Seitenlayouts zu einer Websitesammlung hinzufügen, in der das Feature verwendet wird, ohne dieses erneut zu aktivieren.

Mit dem MapFile-Element können Sie eine URL-Anforderung einer alternativen URL zuordnen. Im folgenden Beispiel wird gezeigt, wie Sie diese Upgradeaktion in eine Feature.xml-Datei integrieren können.

<Feature xmlns="http://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <MapFile FromPath="Features\MapPathDemo_MapPathDemo\PageDeployment\MyExamplePage.aspx"
             ToPath="Features\MapPathDemo_MapPathDemo\PageDeployment\MyExamplePage2.aspx" />
  </UpgradeActions>
</Feature>

Diese Vorgehensweise für das Zuordnen von URLs empfiehlt sich, wenn Sie eine neue Version einer Seite bereitstellen müssen, die mithilfe von SharePoint Designer 2010 angepasst wurde. Die so erstellte angepasste Seite würde aus der Inhaltsdatenbank bereitgestellt werden. Wenn Sie die neue Version der Seite bereitstellen, wird die neue Version nicht angezeigt, weil der Inhalt für diese Seite aus der Datenbank eingelesen wird und nicht aus dem Dateisystem. Dieses Problem können Sie umgehen, indem Sie mithilfe des MapFile-Elements Anforderungen der alten Version der Seite auf eine neuere Version umleiten.

Es ist wichtig zu verstehen, dass die FeatureUpgrading-Methode für jede zu aktualisierende Featureinstanz aufgerufen wird. Wenn Ihre Websitesammlung zehn Websites umfasst und Sie ein Feature mit Webbereich aktualisieren, wird der Featureempfänger zehnmal für jeden Websitekontext aufgerufen. Weitere Informationen zur Verwendung der neuen deklarativen Featureelemente finden Sie unter Änderungen an Feature.xml.

Upgraden von SharePoint 2010-Features: Eine allgemeine Vorgehensweise

Dieser Abschnitt bietet eine grobe Übersicht über die Schritte zur Implementierung dieser Funktionen zur Featureversionsverwaltung und zum Upgraden. Wenn Sie eine neue Version eines Features erstellen, das bereits in einer großen SharePoint 2010-Farm bereitgestellt ist, müssen Sie zwei unterschiedliche Szenarien betrachten: was geschieht, wenn das Feature auf einer neuen Website aktiviert wird, und was passiert auf Websites, auf denen das Feature bereits vorhanden ist. Wenn Sie dem Feature neue Inhalte hinzufügen, müssen Sie zuerst alle vorhandenen Definitionen aktualisieren und Anweisungen zum Upgraden des Features dort, wo es schon bereitgestellt ist, einbinden.

Angenommen, Sie haben einen Inhaltstyp entwickelt, dem Sie eine benutzerdefinierte Websitespalte namens Ort hinzufügen müssen. Dazu gehen Sie wie folgt vor:

  1. Fügen Sie dem Feature eine neue Elementdatei hinzu. Diese Elementdatei definiert die neue Websitespalte und ändert die Datei Feature.xml dahin gehend, dass die Elementdatei integriert wird.

  2. Aktualisieren Sie die vorhandene Definition des Inhaltstyps in der vorhandenen Featureelementdatei. Diese Aktualisierung wird auf alle Websites angewendet, auf denen das Feature neu bereitgestellt und aktiviert wird.

  3. Definieren Sie die erforderlichen Upgradeaktionen für die vorhandenen Websites. In diesem Fall müssen Sie sicherstellen, dass die neu hinzugefügte Elementdatei für die zusätzliche Websitespalte bereitgestellt wird und dass die neue Websitespalte den vorhandenen Inhaltstypen zugeordnet wird. Dazu fügen Sie die Upgradeaktionen ApplyFeatureManifests und AddContentTypeField der Datei Feature.xml hinzu.

Wenn Sie die neue Version des Features in vorhandenen Websites bereitstellen und upgraden, werden die Upgradeaktionen eine nach der anderen auf die Websites angewendet. Wenn Sie benutzerdefinierte Upgradeaktionen definiert haben, wird die FeatureUpgrading-Methode so oft aufgerufen, wie Instanzen des Features in der Websitesammlung oder Farm aktiviert werden.

Abbildung 12 zeigt, wie die verschiedenen Teile dieses Szenarios bei der Durchführung des Upgrades ineinandergreifen.

Abb. 12. Bestandteile eines Featureupgrades, mit dem einem vorhandenen Feature ein neues Element hinzugefügt wird

Hinzufügen eines neuen Elements für ein vorhandenes Feature

Auf verschiedenen Websites können unterschiedliche Versionen eines Features bereitgestellt sein. In diesem Fall können Sie Versionsbereiche erstellen. Diese definieren, welche einzelnen Aktionen beim Upgrade von einer Version auf eine andere ausgeführt werden sollen. Wird kein Versionsbereich definiert, dann werden bei jedem Upgrade alle Upgradeaktionen angewendet.

Abbildung 13 zeigt, wie verschiedene Upgradeaktionen auf Versionsbereiche angewendet werden können.

Abb. 13. Anwenden verschiedener Upgradeaktionen auf Versionsbereiche

Anwenden von Upgradeaktionen für Versionsbereiche

In diesem Beispiel werden, wenn eine gegebene Website direkt von Version 1.0 auf Version 3.0 geupgradet wird, alle Konfigurationen angewendet, weil Sie spezielle Aktionen für das Upgrade von Version 1.0 auf Version 2.0 und von Version 2.0 auf Version 3.0 definiert haben. Sie haben außerdem Aktionen definiert, die unabhängig von der Featureversion angewendet werden.

Richtlinien zum Entwerfen von Code für das Upgraden von SharePoint 2010-Features

Um für den Code eine möglichst hohe Flexibilität zu erhalten, sollten Sie den Upgradecode nicht direkt in den FeatureUpgrading-Ereignisempfänger integrieren. Platzieren Sie den Code stattdessen an einem zentralen Speicherort und verweisen Sie im Ereignisempfänger auf ihn, wie in Abbildung 14 gezeigt.

Abb. 14. Zentraler Featureupgrade-Manager

Upgrade-Manager für Hauptfeatures

Indem Sie den Upgradecode in einer zentralen Hilfsprogrammklasse platzieren, erhöhen Sie die Wiederverwendbarkeit und die Prüfbarkeit des Codes, weil Sie die gleichen Aktionen an mehreren Speicherorten durchführen können. Versuchen Sie auch, die benutzerdefinierten Upgradeaktionen so allgemein wie möglich zu entwerfen, wobei Sie Parameter verwenden, damit Sie sie auf spezielle Upgradeszenarien anwenden können.

Anwendungslebenszyklen: Upgraden von SharePoint 2010-Lösungen

Wenn Sie eine (voll vertrauenswürdige) Farmlösung upgraden, müssen Sie zuerst die neue Version des Lösungspakets in einer Farm bereitstellen.

Führen Sie an einer Eingabeaufforderung eines der folgenden Skripts aus, um Updates in einer SharePoint-Farm bereitzustellen. Im ersten Beispiel wird das Befehlszeilentool Stsadm.exe verwendet.

stsadm -o upgradesolution -name solution.wsp -filename solution.wsp

Im zweiten Beispiel wird das Update-SPSolution Windows PowerShell-Cmdlet verwendet.

Update-SPSolution -Identity contoso_solution.wsp -LiteralPath c:\contoso_solution_v2.wsp -GACDeployment

Nachdem die neue Version bereitgestellt worden ist, können Sie das eigentliche Upgrade durchführen, bei dem die in den Feature.xml-Dateien definierten Upgradeaktionen ausgeführt werden.

Ein Farmlösung-Upgrade kann entweder farmweit oder mithilfe des Objektmodells auf differenzierterer Ebene durchgeführt werden. Für ein farmweites Upgrade verwenden Sie das Befehlszeilentool Psconfig, wie im folgenden Beispiel gezeigt.

psconfig -cmd upgrade -inplace b2b
HinweisHinweis

Dieses Tool verursacht eine Dienstunterbrechung auf den vorhanden Websites. Während des Upgrades werden in der gesamten Farm alle Featureinstanzen geupgradet, für die neuere Versionen verfügbar sind.

Außerdem können Sie Upgrades für einzelne Features auf Websiteebene durchführen. Dazu verwenden Sie die Upgrade-Methode der SPFeature-Klasse. Diese Methode verursacht keine Dienstunterbrechung in der Farm, Sie müssen das Versionsupgrade aber vom Code aus steuern. Ein Codebeispiel, das die Verwendung dieser Methode veranschaulicht, finden Sie unter SPFeature.Upgrade.

Das Upgraden einer Lösung mit eingeschränkter Sicherheitsstufe auf der Ebene der Websitesammlung ist wesentlich einfacher. Dazu laden Sie einfach das SharePoint-Lösungspaket (WSP-Datei) hoch, das die geupgradeten Features enthält. Wenn der Lösungskatalog eine frühere Version einer Lösung mit eingeschränkter Sicherheitsstufe enthält und Sie eine neuere Version hochladen, wird auf der Benutzeroberfläche die Option Upgrade angezeigt, wie in Abbildung 15 gezeigt.

Abb. 15. Upgraden einer Sandkastenlösung

Upgrades für Sandkastenlösungen

Nachdem Sie die Option Upgrade ausgewählt haben, wird das Upgrade gestartet, und alle Features in der Lösung mit eingeschränkter Sicherheitsstufe werden geupgradet.

In diesem Artikel wurden Überlegungen und Beispiele zum Design der Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM) speziell in SharePoint 2010 geschildert. Außerdem wurden die wichtigsten Funktionen und Tools genannt und beschrieben, die Sie in die ALM-Prozesse integrieren können, die in Ihrem Unternehmen eingeführt werden sollen. Das SharePoint 2010-Featureframework und das Modell zum Packen von Lösungen bieten Flexibilität und leistungsstarke Funktionen, die Sie in Ihren ALM-Prozessen wirkungsvoll einsetzen können.

Anzeigen:
© 2015 Microsoft