Freigeben über


SharePoint 2010: Schaffen Sie eine geeignete Umgebung

Die Art und Weise, wie Sie Ihre Entwicklungs- und Testumgebungen einrichten, kann sich erheblich auf die Leistung Ihrer Anwendungen auswirken.

Steve Wright und Corey Erkes

Adaptiert von "Pro SharePoint-2010-Governance" (Apress, 2012)

Im Laufe von jedem großen Entwicklungsprojekt musst du verschiedene Arten von Informationen verwalten. Es empfiehlt sich, ein zentrales Repository für diese Informationen haben, die mit den anderen Werkzeugen verwendet, die vom Entwicklungsteam integriert.

Es gibt mehrere Produkte helfen Ihren Entwicklungsteams zusammenarbeiten und kommunizieren, und Microsoft Visual Studio Team Foundation Server (TFS) hat Vorteile, wenn für die SharePoint-Entwicklung verwendet. Es ist eng mit Visual Studio und SharePoint. Wenn die Organisation kein solches Instrument bereits und wird werden Anwendungen in erster Linie für die Microsoft Windows-Umgebung zu entwickeln, sollten Sie TFS.

Unabhängig von Produkt und Methode Sie auswählen, gibt es einige Funktionen, die eine solche Plattform haben sollte, einschließlich:

  • **Quellcode-Verwaltung:**Dadurch bleibt die Aufzeichnungen über jede Änderung an jede Quelldatei in die Lösung. SharePoint Bibliothek Versionsverwaltung ist nicht für diesen Zweck geeignet. Eine wahre Quellcodeverwaltungssystem unterstützt viele Features über eine Folge von Änderungen nachverfolgen.
  • **Anforderungsmanagement:**Dies zeichnet jeden Fehler, Quelldatei und Arbeit Element in den Anforderungen, auf die es sich bezieht.
  • **Arbeitsaufgabenverfolgung:**Dies meldet die Bug-Reports, Helpdesk-Tickets, Feature-Wünsche, Veröffentlichungen und Aufgaben im Zusammenhang mit dem Projekt.
  • **Automatisierung zu bauen:**Dies kompiliert Quelldateien in einsetzbare Projektmappendateien.
  • **Testmanagement:**Dies zeichnet automatische und manuelle Testfälle, automatisiert Regression und Unit-Tests, verwaltet Bereitstellung zum Testen von Server-Farmen und Belastungstests führt.

Nicht alle Team-Entwicklungs-Plattformen werden all diese Funktionen unterstützen. Quellcodeverwaltung ist jedoch eine Funktion, die absolut eine stabile Anwendung Basis beibehalten werden muss. Die anderen Funktionen können mehr oder weniger wichtig, eine bestimmte Organisation sein. Es kann auch für separate, nicht integrierte Tools für diese Funktionen zu verwenden.

Entwickler-Umgebungen

Einer der schwierigeren Aspekte der SharePoint-Entwicklung ist eine produktive Entwicklungsumgebung zu etablieren. Dies bezieht sich auf den Bereich, in dem ein einzelner Entwickler arbeiten können, erstellen und Debuggen von seinem zugewiesenen Komponenten oder Updates. SharePoint ist eine serverseitige Technologie, so dass Komponenten, die auf einem SharePoint-Server im allgemeinen laufen auch auf einem entwickelt werden müssen.

Ein häufiger Fehler ist es, eine "" vom verwendeten Entwicklungsserver alle Team-Entwickler haben. Wenn Teammitglieder völlig unabhängige Komponenten arbeiten und nie müssen gemeinsame tun Dinge wie IIS neu starten oder einen Debugger an einen IIS-Prozess anfügen, funktioniert diese Art der Umgebung nicht im Allgemeinen gut. Entwickler brauchen vollständige Kontrolle über den Server Probleme effektiv zu debuggen. Entwickler voneinander zu isolieren, ist der beste Weg, um alle produktiv zu halten.

Ein weiteres Missverständnis ist, dass Sie können auf einem Clientsystem ausführen Visual Studio entwickeln und Debuggen auf einem Remoteserver mit SharePoint. Während Sie eine SharePoint-Lösung auf einem anderen Server Debuggen können, müssen Sie noch SharePoint auf der SharePoint Server-seitige Code kompilieren System installiert haben. Die Bibliotheken, die der serverseitige Code verwendet sind nur auf einem SharePoint-Server verfügbar. Sie können nicht auf einem Clientcomputer damit Code kompiliert werden kann separat installiert werden. Wenn Sie Client-Anwendungen verwenden nur die neue Client-Objektmodelle (Client OMs) eingeführt, die mit SharePoint 2010 entwickeln, können Sie sie auf einem System kompilieren, die SharePoint installiert nicht.

Eine minimale SharePoint Entwicklungsumgebung sollte Folgendes beinhalten:

  • Eine 64-Bit-Windows-OS kompatibel mit SharePoint 2010 (Windows 2008, Windows Vista SP1 oder Windows 7)
  • Visual Studio 2010
  • SQL Server Express Edition
  • SharePoint Foundation oder Server-Komponenten nach Bedarf

Die folgenden Tools sind oft hilfreich und Sie sollten diese aufnehmen, wann immer möglich:

  • Microsoft Office -Anwendungen
  • SQL Server Developer Edition
  • Microsoft Visio
  • InfoPath-Designer
  • SharePoint Designer (kostenloser Download)

Sie haben auch mehrere Wahlmöglichkeiten hinsichtlich wo Sie diese Tools zu installieren. Die erste und einfachste Möglichkeit ist, alle Tools und SharePoint direkt auf der Entwickler-Computer zu laden. Dies erfordert eine 64-Bit-Betriebssystem kompatibel mit SharePoint. Diese Konfiguration ist einfach zu bedienen, da alle notwendigen Werkzeuge verfügbar sind.

Leider ist diese Konfiguration begrenzt durch die Kraft des Desktopcomputers, die Speicherung von der Festplatte, und die Tatsache, dass Sie nur ein SharePoint-Konfiguration verwenden können. Ein Entwickler, der häufig zwischen Projekten bewegt könnte diese Art der Konfiguration schwer zu verwalten.

Entwicklung Umgebungsoptionen

Die nächste Option ist eine desktop-Virtualisierungsprodukt wie Oracle VirtualBox oder VMware Workstation verwenden. Wieder müssen Sie sichergehen, dass unabhängig davon, welche Virtualisierungstool, das Sie verwenden eine 64-Bit-Gast-Betriebssystem unterstützt. Diese Konfiguration hat viele der gleichen Einschränkungen wie installieren die Umgebung direkt auf dem Desktop. In der Regel Leistung ist nicht sehr gut, und Sie benötigen große Festplattendateien, desktop-Virtualisierung zu unterstützen.

Der Vorteil dieser Art von Umgebung ist, dass Sie mehrere SharePoint-Konfigurationen in separaten virtuellen Maschinen (VMs) auf demselben Desktop hosten können. In der Regel lassen sich Speicher und Leistungsanforderungen nicht mehrere VM jedoch zu einem Zeitpunkt ausführen.

Sie können auch eine virtuelle Festplatte (VHD) Datei erstellen und führen Sie es direkt auf das System ohne den Umweg über eine desktop-Virtualisierungsprodukt. Dies ist vergleichbar mit der alten "Dual-Boot"-Setup für ein System. Anstatt eine separate Partition für die zweite OS, würden Sie eine VHD-Datei in die vorhandene OS-Dateisystem verwenden. Diese Konfiguration hat den Vorteil der Verwendung des Systems Hardware ohne einen zweiten OS in Folge den Development Server hosten.

Der einzige Nachteil ist, dass alle Anwendungen auf dem Desktop-Client-Betriebssystem geladen nicht während der Ausführung der Entwicklungsumgebung zur Verfügung stehen. Dies ist die beliebteste Konfiguration für SharePoint-Entwickler schnell immer, da es die Flexibilität der desktop-Virtualisierung bietet, ohne die Leistung Kosten. Weitere Informationen zum Ausführen mehrerer Betriebssysteme, die mit die neue Windows 7 Boot-Konfiguration, siehe Keith Combs' Blog-post, "Dual-Boot von VHD Using Windows 7 und Windows Server 2008 R2."

Die endgültige Konfiguration verwendet Server-Virtualisierung. Dies könnte Microsoft Hyper-V, VMWare oder anderen Server Virtualisierung. Dies ist eine ausgezeichnete Wahl für ein Unternehmen mit einer guten Virtualisierungsinfrastruktur. Eine VM auf einem VM-Host-Server bereitgestellt und verwenden Sie diesen Server, um die gesamte Entwicklungsumgebung Haus.

Mit einem Remote Desktop Protocol (RDP)-Client, hat Ihr Entwickler Zugriff auf eine vollständige Umgebung ohne Änderungen oder Installationen auf seine Umgebung. Der einzige Nachteil bei dieser Konfiguration ist, dass Sie mit dem VM-Server verbinden, um Entwicklungsaufgaben ausführen können müssen. Sie können nicht "take it with you."

Testumgebungen

Sobald die Entwicklung abgeschlossen ist, müssen Sie die Anwendung durch eine strenge, klar definierte Testverfahren Therapie zu setzen. Dies erfordert, dass Sie es in ein oder mehrere Testumgebungen vor der Bereitstellung in der Produktionsumgebung zu laden. Diese Umgebungen gehen viele Namen, einschließlich Integration, Test, Bühne, Benutzerakzeptanztests (UAT), Vorproduktion und so weiter.

Sie könnte eine Integrationsfarm verwenden, um alle kompilierten Komponenten in einer Umgebung zu testen, die keine Entwicklungs-Tools enthält. Das Vorhandensein von Visual Studio oder andere Entwicklungs-Tools auf einem System kann manchmal Störungen verbergen, die nur auftreten, wenn diese Werkzeuge nicht verfügbar sind.

Sobald die Freigabe getestet wird, liefern sie an der Qualität-Qualitätssicherung-Gruppe oder welcher Abteilung für UAT verantwortlich ist. Anschließend lädt die Testgruppe die Freigabe der Pre-Production-Farm. Diese Farm sollte so ähnlich wie der Produktionsfarm wie möglich zu helfen, die Testgruppe der Veröffentlichung Produktion Bereitschaft zu beurteilen.

Beispielsweise wenn die Produktionsfarm mehrere Front-End-Webserver verfügt, sollte also auch die Pre-Production-Farm. Virtuelle Server sind oft für physische Server die Testumgebungen kostengünstiger machen ersetzt. Sobald UAT abgeschlossen ist, können Sie die Anwendung in der Endproduktion-Serverfarm bereitstellen.

Wenn Sie eine neue Version zu testen, ist es wichtig, Inhalte wie der Inhalt in der Produktion möglichst ähnlich zu verwenden. Wenn ein Benutzer ein Element auf einer Website in der Produktionsfarm angepasst hat, der eine Änderung an der Anwendung behindert, könnten Sie z. B. nicht bemerken, wenn die Änderung nur für "faule" Testdaten getestet wird. Eine ausgezeichnete Quelle für realistische Content-Daten für die Prüfung ist der Produktionsserverfarm. Sie können ganz einfach sichern und Wiederherstellen die Produktion Inhaltsdatenbanken in Testumgebungen in den meisten Fällen.

Eine andere häufig verwendete Konfigurationen für testen und Bereitstellen von SharePoint-Anwendungen ist eine staging-Server-Farm zu verwenden. Mit dieser Technik gibt es zwei komplette Serverfarmen, die zu allen Zeiten. Verwenden Sie Ihren Benutzern eine und die andere steht die neue Version zu erhalten. Sobald die Freigabe der staging Farm bereitgestellt wird, ist das Netzwerk neu konfiguriert, um eingehenden Datenverkehr an die Stagingfarm weiterleiten. So die staging-Server werden Produktion und die Produktions-Server zu wechseln, für die Inszenierung.

Dies ist eine nützliche Technik für öffentlich zugängliche Websites, auf denen Sie Ausfallzeiten erlauben können nicht. Der Zeitaufwand zum Austauschen der Serverfarmen ist nur so lange, wie es braucht, um den Datenverkehr im Netzwerk umleiten. Natürlich ist es wichtig, dass alle Produktion Content-Updates auf der Stagingfarm vor der Bereitstellung des neuen Release verschoben werden. Um Aktualisierungen zu verhindern, nach der Inhalt Start kopiert wird, kann SharePoint Sie vorübergehend sperren Inhaltsdatenbanken.

Wenn Sie diese Technik verwenden, kann die staging-Umgebung auch als hot Standby für die Produktionsfarm dienen. Wenn Produktion einen schwerwiegenden Fehler leidet, können Sie schnell den staging-Server bringen, um Dienst wiederherzustellen. Wenn dies Ihr Disaster-Recovery-Plan gehört, sollten Sie auch, wenn Sie neue Versionen bereitstellen sind nicht regelmäßig Produktion Inhalt staging Farm kopieren. Es wäre auch sinnvoll, die Test- und Produktionsumgebungen Farmen gehostet in separate physische Standorte Standort Redundanz bereitstellen zu lassen. Alle diese Techniken und Konfigurationen können Sie eine SharePoint-Entwicklungsumgebung zu entwickeln, die am besten Ihren Bedürfnissen und Ressourcen.

Steve Wright

Steve Wright ist senior Manager im Bereich Business Intelligence Management (BIM) für Sogeti USA LLC in Omaha, Neb. In den Jahren zuletzt formte arbeitete Wright Flugsicherung, Finanz-, Versicherungs- und eine Vielzahl anderer Typen von Systemen an. Er hat Autor und technische Rezensionen für viele vorherige Titel für Microsoft-Produkte, einschließlich Windows, SharePoint, SQL Server und BizTalk durchgeführt.

Corey Erkes

Corey Erkes ist ein Manager-Berater für Sogeti USA LLC in Omaha, Neb. Erkes arbeitete mit einer Vielzahl von Firmen zu verschiedenen Zeitpunkten der Lebenszyklen ihrer SharePoint-Implementierungen. Er ist auch einer der Gründungsmitglieder der Omaha-SharePoint-Benutzergruppe.

© 2012 Apress Inc. Alle Rechte vorbehalten. Gedruckt mit Genehmigung von Apress. Copyright 2012. "Pro SharePoint 2012 Governance" von Steve Wright und Corey Erkes. Für weitere Informationen zu diesem Titel und andere ähnliche Bücher, besuchen Sie bitte apress.com.

Verwandte Inhalte