SharePoint 2010 : Créez l'environnement approprié
La façon dont vous configurez votre développement, ainsi que vos environnements et vos processus de test, peut avoir un impact important sur vos applications.
Steve Wright et Corey Erkes
Adapté de « Pro SharePoint 2010 Governance » (Apress, 2012)
Au cours de n'importe quel projet de développement important, vous devrez gérer différents types d'informations. Il est préférable d'avoir un dépôt central pour cette information qui s'intègre avec les autres outils utilisés par l'équipe de développement.
Il existe plusieurs produits pour aider vos équipes de développement de collaborer et de communiquer, et Microsoft Visual Studio Team Foundation Server (TFS) présente des avantages lorsqu'il est utilisé pour le développement SharePoint. Il est étroitement intégré à Visual Studio et SharePoint. Si votre organisation n'a déjà pas un tel outil et développera des applications principalement pour l'environnement de Microsoft Windows, vous devez envisager de TFS.
Quel que soit le produit et la méthode que vous choisissez, il y a quelques caractéristiques qui ait une telle plate-forme, y compris :
- **Contrôle de Code source :**Cela tient un registre de tous les changements à chaque fichier source dans la solution. Versioning de bibliothèque SharePoint n'est pas approprié à cet effet. Un système de contrôle source véritable prend en charge de nombreuses fonctionnalités au-delà d'une seule séquence de modifications apportées au fichier de suivi.
- **Gestion d'exigence :**Cela localise chaque bogue, travail et fichier source point de retour aux exigences qui lui est liée.
- **Suivi des éléments de travail :**Cela enregistre les rapports de bogues, help desk billets, feature requests, communiqués et tâches associées au projet.
- **Construire l'automatisation :**Ceci compile les fichiers source en fichiers solution déployable.
- **Gestion des tests :**Cela enregistre des cas de tests automatisés et manuels, automatise la régression et des tests unitaires, gère le déploiement pour tester les batteries de serveurs et effectue des tests de charge.
Pas toutes les plateformes de développement d'équipe soutiendra toutes ces caractéristiques. Toutefois, le contrôle de code source est une fonction qui est absolument nécessaire de maintenir une application stable base. Les autres fonctions peuvent être plus ou moins importantes à une organisation particulière. Il peut également être acceptable d'utiliser des outils distincts, non intégrées pour ces fonctions.
Environnements développeur
Un des aspects plus difficiles du développement SharePoint met en place un environnement de développement productif. Il s'agit de la zone où un développeur peut travailler pour créer et déboguer des ses composantes assignées ou mises à jour. SharePoint est une technologie côté serveur, donc les composants conçus pour fonctionner sur un serveur SharePoint en général doivent être développées sur un aussi bien.
Une erreur courante consiste à disposer d'un « serveur de développement » utilisé par tous les développeurs de l'équipe. À moins que les membres de l'équipe travaillent sur des composants totalement indépendants et jamais besoin de faire commun choses tels que redémarrer IIS ou attacher un débogueur à un processus IIS, ce type d'environnement ne fonctionne généralement bien. Les développeurs ont besoin d'un contrôle complet sur le serveur pour résoudre efficacement les problèmes. Isoler les uns des développeurs est la meilleure façon de garder tout le monde productif.
Une autre idée fausse est que vous pouvez développer sur un système client, exécutez Visual Studio et déboguer sur un serveur distant exécutant SharePoint. Alors que vous pouvez déboguer une solution SharePoint en cours d'exécution sur un autre serveur, vous devez toujours avoir SharePoint installée sur le système de compilation de code côté serveur SharePoint. Les bibliothèques qu'utilise le code côté serveur sont disponibles uniquement sur un serveur SharePoint. Vous ne pouvez pas les installer séparément sur un ordinateur client pour permettre au code à compiler. Si vous développez des applications clientes en utilisant seulement les nouveaux modèles d'objet Client (Client SGD) disponible dans SharePoint 2010, vous pouvez les compiler sur un système qui n'a pas installé de SharePoint.
Un environnement de développement SharePoint minimal doit inclure ce qui suit :
- Un OS de Windows 64-bit compatible avec SharePoint 2010 (Windows 2008, Windows Vista SP1 ou Windows 7)
- Visual Studio 2010
- SQL Server Express
- Composants SharePoint Foundation ou serveur selon les besoins
Les outils suivants sont souvent utiles et vous devez inclure ces lorsque c'est possible :
- Microsoft Office
- SQL Server Developer Edition
- Microsoft Visio
- InfoPath Designer
- SharePoint Designer (Téléchargement gratuit)
Vous avez aussi plusieurs options à considérer en matière où vous installez ces outils. La première et la plus simple consiste à charger tous les outils et SharePoint directement sur l'ordinateur du développeur. Cela nécessite un système d'exploitation 64 bits compatible avec SharePoint. Cette configuration est facile à utiliser, car tous les outils nécessaires sont facilement disponibles.
Malheureusement, cette configuration est limitée par la puissance de l'ordinateur de bureau, le stockage de disque dur et le fait que vous ne pouvez utiliser une configuration de SharePoint. Un développeur qui se déplace fréquemment entre projets pourrait trouver ce type de configuration difficile à gérer.
Options d'environnement de développement
L'option suivante est d'utiliser un produit de virtualisation de bureau tels que Oracle VirtualBox ou VMware Workstation. Encore une fois, vous devez être certain que n'importe quel outil de virtualisation vous utilisez prend en charge 64-bit OS invité. Cette configuration a beaucoup des mêmes restrictions comme l'installation de l'environnement directement sur le bureau. En général, la performance n'est pas très bon et vous aurez besoin des fichiers de disques de grande capacité à supporter la virtualisation.
L'avantage de ce type d'environnement, c'est qu'il vous permet d'héberger plusieurs configurations de SharePoint dans des machines virtuelles (VM) distinctes sur le même bureau. En général, conditions de performance et de la mémoire ne vous permettent d'exécuter plus d'une machine virtuelle à la fois, cependant.
Vous pouvez également créer un fichier de disque dur virtuel (VHD) et exécutez-le directement sur le système sans passer par un produit de virtualisation de bureau. Ceci est similaire à la configuration de vieux « dual-boot » pour un système. Au lieu d'utiliser une partition séparée pour le deuxième système d'exploitation, vous devez utiliser un fichier VHD dans le système de fichiers d'OS existant. Cette configuration a l'avantage d'utiliser tout matériel du système, sans nécessiter une deuxième consécutive de l'OS pour héberger le serveur de développement.
Le seul inconvénient est que les applications chargées sur le client de l'ordinateur de bureau système d'exploitation ne sont pas disponibles lors de l'exécution de l'environnement de développement. Cela devient rapidement la configuration la plus populaire pour les développeurs SharePoint, car il vous offre la possibilité de virtualisation sans encourir des coûts de performance. Pour plus d'informations sur l'exécution de plusieurs systèmes d'exploitation à l'aide de la nouvelle configuration de démarrage de Windows 7, voir Keith Combs blog, "Dual Boot VHD à l'aide de Windows 7 et Windows Server 2008 R2. »
La configuration finale utilise la virtualisation des serveurs. Cela pourrait être Microsoft Hyper-V, VMWare ou tout autre produit de virtualisation de serveur. Il s'agit d'une excellente option pour une entreprise disposant d'une infrastructure de virtualisation bon. Mis en service une machine virtuelle sur un serveur hôte VM et utiliser ce serveur pour héberger l'environnement de développement complet.
À l'aide d'un client de Remote Desktop Protocol (RDP), votre développeur a accès à un environnement complet sans faire des modifications ou des installations sur son environnement local. Le seul inconvénient avec cette configuration, c'est que vous devez être capable de se connecter au serveur VM pour effectuer les tâches de développement. Vous ne pouvez pas « emportez-le avec vous. »
Environnements de test
Une fois que le développement est terminé, vous devrez mettre la demande grâce à un régime d'essai rigoureux et bien définie. Cela nécessite que vous charger dans un ou plusieurs environnements de non-parution avant le déploiement en production. Ces environnements aller sous plusieurs noms, y compris d'intégration, test, stade, tests d'acceptation utilisateur (UAT), pré-production et ainsi de suite.
Vous pourriez utiliser une ferme d'intégration pour tester tous les composants compilés dans un environnement qui ne contient pas d'outils de développement. La présence de Visual Studio ou autres outils de développement sur un système peut parfois masquer les erreurs survenant uniquement lorsque ces outils ne sont pas disponibles.
Une fois que la version est testée, remettre au groupe d'assurance de la qualité, ou n'importe quel ministère est responsable de l'UAT. Alors, ce groupe de test chargera la sortie à la ferme de pré-production. Cette ferme devrait être comme semblable à la ferme de production que possible pour aider le groupe de tests évaluer de la version production.
Par exemple, si la ferme dispose de plusieurs serveurs Web frontaux, donc, aussi, si la ferme de pré-production. Serveurs virtuels sont souvent substituées pour serveurs physiques rendre les environnements de test plus rentable. Une fois que l'UAT est terminée, vous pouvez déployer l'application à la batterie de serveurs de production finale.
Lorsque vous testez une nouvelle version, il est important d'utiliser le contenu comme étant similaire au contenu dans la production que possible. Par exemple, si un utilisateur a personnalisé un élément dans un site à la ferme d'élevage qui interfère avec une modification apportée à l'application, vous remarquerez pas si le changement a seulement été testé contre les données de test « bidon ». Une excellente source de données de contenu réalistes pour les tests est la batterie de serveurs de production. Vous pouvez facilement sauvegarder et restaurer les bases de données contenu de production dans les environnements de test, dans la plupart des cas.
Une autre configuration courante pour tester et déployer des applications SharePoint consiste à utiliser une batterie de serveurs intermédiaires. Avec cette technique, il y a deux batteries de serveurs complète fonctionner en permanence. Vos utilisateurs utilisent l'un et l'autre s'en tient à recevoir la nouvelle version. Une fois que la libération est déployée sur la batterie de transit, le réseau est reconfiguré pour acheminer le trafic entrant à la batterie de transit. Ainsi, les serveurs de la zone de transit deviennent production et placez-vous dans les serveurs de production mise en scène.
Il s'agit d'une technique utile pour les sites au public sur lequel vous ne pouvez autoriser les interruptions de service. Le temps nécessaire pour remplacer les batteries de serveurs est seulement aussi longtemps qu'il le faudra pour rediriger le trafic réseau. Évidemment, il est essentiel que toutes les mises à jour contenu de production sont déplacés vers la batterie de transit avant de déployer la nouvelle version. Pour empêcher les mises à jour après que le contenu commence à être copié, SharePoint permet temporairement des bases de données de verrouillage.
Lorsque vous utilisez cette technique, l'environnement intermédiaire peut également servir un secours pour la batterie de serveurs de production. Si la production subit une défaillance catastrophique, vous pouvez rapidement afficher le serveur intermédiaire pour rétablir le service. Si cela fait partie de votre plan de récupération après sinistre, vous devez régulièrement copier contenu de production sur la batterie de transit, même lorsque vous n'êtes pas un déploiement nouveautés. Il peut également être utile d'avoir des fermes intermédiaires et de production, hébergés dans des lieux physiques distincts pour fournir une redondance de l'emplacement. Aucune de ces techniques et configurations peut vous aider à développer un environnement de développement SharePoint qui répond le mieux à vos besoins et vos ressources.
.jpg)
Steve Wright est un cadre supérieur en gestion d'entreprise intelligence (BIM) pour Sogeti USA LLC à Omaha, au Nebraska. Au cours des dernière plus de 20 ans, Wright a travaillé sur le contrôle du trafic aérien, financier, d'assurance et une multitude d'autres types de systèmes. Il a été auteur et effectué des examens techniques pour nombreux titres précédents portant sur les produits Microsoft, notamment Windows, SharePoint, SQL Server et BizTalk.
.jpg)
Corey Erkes est consultant manager pour Sogeti USA LLC à Omaha, au Nebraska. Erkes a travaillé avec un large éventail de sociétés à différents points dans les cycles de vie de leurs implémentations de SharePoint. Il est également l'un des membres fondateurs du groupe d'utilisateurs de SharePoint Omaha.
© 2012 Apress Inc. Tous droits réservés. Imprimé avec l'autorisation d'Apress. Copyright 2012. « Gouvernance pro SharePoint 2012 » par Steve Wright et Corey Erkes. Pour plus d'informations sur ce titre et autres ouvrages semblables, s'il vous plaît visitez apress.com.