Environnements de développement/production SharePoint

Question

L'un des plus grands défis que j'ai rencontrés avec SharePoint est qu'il ne se prête pas bien à l'environnement de projet typique, qui, au minimum, contient des environnements de développement et de production. Les problèmes que j'ai le plus souvent rencontrés sont que le contenu et les listes sont si étroitement couplés qu'il est difficile d'effectuer des modifications de conception sans effectuer un gel de contenu sur l'environnement de production. Par exemple, si j'avais une liste avec des colonnes calculées et que je voulais ajouter de nouvelles fonctionnalités, je devrais faire un gel de contenu sur le serveur de production, créer un modèle de liste (y compris le contenu) du serveur de production, restaurer cette liste. environnement de développement, apporter mes modifications, puis inverser le processus de modèle de liste. La même chose vaut pour les pages et à peu près n'importe quoi d'autre dans SharePoint. Il semble qu'une fois le site déployé, il vaut mieux travailler directement sur la boîte de production, mais cela brise une tonne de bonnes pratiques, pour des raisons évidentes. Comment certains d'entre vous autres développeurs SharePoint gèrent-ils cette limitation?

Answer 1

Il y a vraiment deux (plus?) Niveaux de "développement" SharePoint. Vous avez le code qui est déployé sur le serveur, tel que les composants WebPart, les types de contenu, les actions de workflow, etc. Cela fonctionne relativement bien en termes de déploiement et de meilleures pratiques.

Ensuite, vous avez votre exemple, qui est plus d'une personnalisation des instances de site. Ce que nous avons fait lorsque nous avons dû personnaliser un champ calculé dans la liste du répertoire du site du portail, c'est d'essayer de modifier les changements de développement. Rédigez ensuite des instructions détaillées sur la personnalisation à effectuer et demandez à une personne distincte disposant des autorisations appropriées d'utiliser ces instructions pour effectuer la modification sur un serveur d'intégration (staging). Ensuite, la même personne fait les changements en direct sur la production. Je ne suis pas sûr si vos changements sont sensibles à cette approche, mais il vaut la peine d'envisager. Ensuite, nous avons un autre site qui est fortement personnalisé avec SharePoint designer, et celui que nous travaillons en direct.

Answer 2

Vous pouvez utiliser l'Assistant de déploiement de contenu (http://www.codeplex.com/SPDeploymentWizard) pour migrer rapidement des éléments tels que des listes et des bibliothèques. Vous pouvez également prendre une copie de sauvegarde/restauration de la production, puis apporter vos modifications, puis au petit matin, faire un gel de contenu (espérons que personne ne s'en souciera), importer toutes les données modifiées de la production dans votre copie , puis restaurer la copie sur la production. Au moins, le gel pourrait être reporté et ne serait nécessaire que pendant la durée de la procédure export-> import-> restore.

En pratique, je fais juste mes changements de production à la main.

Answer 3

Utilisez le code FeatureActivation pour déployer les modifications dans les champs des listes. Une fois le code mis à jour les champs, vous désactivez la fonction et la supprimez. Ceci permet aux résultats d'être testés dans un environnement d'assurance qualité avant la main.