Meilleures pratiques pour appliquer des modifications à une application SharePoint

Question

J'ai l'impression d'avoir besoin d'un cadre mieux défini pour mettre à jour mon application SharePoint (MOSS 2007) avec des modifications de code personnalisées. Je crée des fichiers de solution wsp avec des fonctionnalités et de nouveaux types, mais une fois ceux-ci testés et déployés, j'ai l'impression que c'est un peu un acte de foi, et cela me rend nerveux et parfois réticent à déployer des changements. Après le déploiement, il est difficile de corréler l'état actuel de l'application SharePoint avec le code spécifique qui est déployé sur ce serveur SharePoint. Quelles fonctionnalités sont réellement installées et sur quels sites? Quelles fonctionnalités sont activées ou désactivées? Quelle version de ce champ personnalisé ou type de contenu est vraiment là? Des choses comme ça. Si une erreur survient, je dois me fier à mes suppositions sur le code qui est en train de tourner, ou je dois passer du temps à creuser des assemblages déployés et la ruche - pas impossible, mais plutôt désagréable.

Quelles mesures dois-je prendre pour améliorer ma capacité à déterminer sans ambiguïté l'état de l'application et trouver le code qui représente vraiment cet état? Existe-t-il des outils tiers pouvant vous aider?

Answer 1

Je ressens votre douleur ... Application Développement Le cycle de vie avec SharePoint 2007 me laisse un goût amer dans la bouche.

Pour répondre à votre question. Nous avons construit notre propre utilitaire de déploiement qui fait quelques choses pour nous.

1. chèques état des postes clés minuterie (trop de fois nous faire un déploiement pour trouver un WFE qui n'a pas obtenu le déploiement)

2. chèques état des services clés sur toutes nos extrémités avant web (encore une fois nous voulons connaître la santé de la ferme avant de débuter les travaux du minuteur).

3. Affiche la version du fichier et la date des assemblages sélectionnés à partir de GAC (pour tous les frontaux Web). Nous avons déjà vu des problèmes où les assemblages n'étaient pas installés correctement dans les fermes.

4. Met à jour les paramètres web.config en fonction d'un schéma XML personnalisé que nous fournissons. Nous avons rencontré des problèmes avec les mises à jour de web.config. Nous avons donc pensé à créer un utilitaire pour valider le fichier web.config (assurez-vous qu'il n'y a pas d'entrées en double pour des clés spécifiques).

5. Poussez les mises à jour de type de contenu (les premiers types de contenu sont déployés par l'intermédiaire d'une fonctionnalité, mais dès que vous devez mettre à jour ce type de contenu, cela devient difficile).

6. Vérifie l'état du package WSP après le déploiement ou la mise à niveau.

Cet utilitaire utilise l'API SharePoint pour effectuer la majeure partie de ce travail.Une partie est effectuée en vérifiant les événements WMI.

Answer 2

Malheureusement, l'expérience de développement de SharePoint fait défaut à cet égard. Tant que vous «gérez» toutes les fonctions déployées à l'aide de packages de solutions, vous pouvez utiliser la gestion de solution à partir de l'administrateur central pour suivre les versions et ce qui est déployé sur la collection de sites.

Les fonctionnalités s'étendent de tous les niveaux, de la ferme à une bande individuelle; Donc la maintenance à partir de ce niveau est un peu difficile. J'essaye juste d'organiser tout le code déployé du niveau de la solution (du haut vers le bas).

Cela devient encore plus compliqué lors du déploiement de travaux de minuteur personnalisés, de gestionnaires d'événements, etc. J'espère vraiment que cette version abordera beaucoup de ces préoccupations communes de développement.

Answer 3

est-ce pas la seule façon que vous avez un processus de déploiement planifié/contrôlé et un système de gestion de version comme TFS

Dans le projet actuel, je suis impliqué dans nous avons:

1. continue builds
2. Daily Builds sur un serveur de développement
3. Lorsque nous publierons quelque chose à tester, nous fusionnons le code au Bransch principal dans le système de gestion de version (TFS)
4. Lorsque testé et prêt pour la production puis nous fusionnons la principale Bransch à la libération Bransch

L'utilisation de cette manière structurée, nous sait toujours ce qui est déployé dans quel environnement et peut également suivre tous les changements en fonction de l'environnement ou des changements dans les exigences (sont également suivis dans TFS)