Industrialiser les Personnalisations Microsoft SharePoint « autrement »

​Introduction Nous allons aborder dans cet article la portabilité des personnalisations d’une collection de site Microsoft SharePoint à une autre, entre deux ferme différentes ou au sein d’une même ferme SharePoint en se basant sur DocAve 6 Deployment Manager. Industrialiser les personnalisations SharePoint « autrement » SharePoint, comme toute plateforme de développement dispose de ses propres règles. Le cycle de développement SharePoint, de manière générale commence par une maquette qui porte le besoin exprimé par le métier. Cette maquette est créée à partir de l’interface SharePoint via le navigateur ou en utilisant SharePoint Designer. L’élaboration d’une maquette SharePoint consiste en : ​· l’activation de fonctionnalités nécessaires au besoin exprimé par le métier : publication, Workflow,… · Création des métadonnées (colonnes) et des descripteurs des structures métier (Types de contenu) · Personnalisation de la charte graphique : cette étape englobe la personnalisation des pages maitres du site et des gabarits de page de publication, mais aussi la copie des ressources visuelles comme les images, les icones, les fichiers de styles et de javascript. Les personnalisations sont effectuées, à cette étape, par SharePoint Designer · Définition des groupes de sécurité et des niveaux de permissions Une fois que la maquette est créée et validée, l’équipe de développement SharePoint doit passer à la phase d’industrialisation. Ce qu’on appelle phase d’industrialisation est le portage des personnalisations d’un environnement de test ou de maquette à un environnement de production. Il existe plusieurs méthodes d’industrialisation dans SharePoint, voici les plus utilisées : · Empaqueter les personnalisations dans une solution SharePoint (wsp) · Sauvegarder la maquette puis la restaurer sur la production · Utiliser des sites template La voie royale de portage des personnalisations reste encore l’utilisation des solutions SharePoint. Je ne vais pas détailler les limitations de chacune des méthodes car elles sont connues, je vais me restreindre au portage des personnalisations via les solutions SharePoint. Avant de se lancer dans des développements SharePoint, il faut s’assurer des prérequis suivants : · Disposer d’une équipe de développements qualifiée · Réfléchir sur les cycles de développements avec toutes les contraintes liées : Architecture logicielle, tests… · Disposer des ressources nécessaires pour maintenir du code spécifique (TMA) · Se poser la question des compatibilités des développements personnalisées lors d’un upgrade SharePoint, notamment ceux des définitions des listes et des définitions de sites Les éléments cités dessus mettent en évidence la complexité d’organiser des développements SharePoint. Cela ne veut pas dire qu’il faille bannir les développements SharePoint, car la richesse de son « API » est clairement un de ses atouts majeurs, mais il faut limiter les développements au minimum en privilégiant les fonctionnalités « Out of the box ». Mais comment le faire ? en s’appuyant sur des outils du marché, car il existe un écosystème d‘ISV dédié à SharePoint assez développé. Il est « naturel » que je vous présente. Dans ce qui suit, je vais présenter DocAve Deployment Manager, solution édité par AvePoint ainsi que deux scenarii classiques de déploiement de SharePoint pour lesquels DocAve Deployment Manager convient parfaitement. DocAve 6 Deployment Manager DocAve 6 permet le portage des personnalisations d’une plateforme SharePoint à une autre. Les éléments de configuration supportés par DocAve Deployment Manager sont : · Les éléments de design · Les composants des frontaux · Les solutions SharePoint (wsp) · Les magasins de termes SharePoint (locaux et globaux) 1. Eléments de design Les éléments de design sont les conteneurs SharePoint à différents niveaux avec leurs configurations ainsi que leur contenu. DocAve Deployment Manager 6 fait bien la différence entre les conteneurs systèmes (Design lists : listes créées à partir de fonctionnalités SharePoint comme les librairies propres aux fonctionnalités de publication) et les conteneurs utilisateurs (Lists : Listes destinées à héberger le contenu utilisateur). 2. Composants des frontaux Les composants des frontaux sont les répertoires nécessaires au bon fonctionnement de SharePoint. Ces répertoires sont : · Les sites IIS · Les répertoires des fonctionnalités et des définitions de sites SharePoint · Le Global Assembly Cache 3. Solutions SharePoint (wsp) Permet de déployer les solutions SharePoint indépendamment de leur type : Ferme ou sandbox. En fonction de l’état de la solution (wsp) dans la plateforme de destination, DocAve permet de faire un « upgrade » ou un « retract/re-deploy ». 4. Les magasins de terme Permet de porter des magasins de terme indépendamment de leur type : locaux ou globaux. 5. Plan de déploiement DocAve porte les personnalisations d’une plateforme à une autre ou au sein d’une même plateforme via une interface intuitive. Cette interface permet de créer des plans de déploiement. Globalement dans DocAve 6 et indépendamment des modules utilisés, un plan DocAve 6 permet de : · Planifier son l’exécution · Avoir des logs d’exécution et des notifications par mail à la fin de l’exécution · Avoir les dates et heures de début d’exécution, de fin d’exécution et un statut d’exécution Un plan de déploiement DocAve 6 est en plus constitué d’une queue d’actions. Cette conception de plan DocAve Deployment Manager 6 vient du fait qu’un déploiement SharePoint, de manière générale, est constitué de plusieurs actions dépendantes les unes des autres. Porter une collection de site d’une ferme à une autre nécessite que les fonctionnalités soient installées dans la ferme de destination. Sauf que l’installation des personnalisations nécessite au préalable le déploiement de solutions indépendamment de leur type (ferme ou sandbox), ou peut-être la validation de certains paramètres via un script…Le portage des personnalisations permet aussi le déplacement de contenu. Cela veut dire qu’on est capable de déplacer du contenu d’un bac à sable vers une production en ayant le choix sur les éléments à inclure et sur la manière de gérer des conflits si le contenu à déplacer existe déjà dans la destination. Lors du portage/déplacement d’une collection de sites, un certain nombre de configuration lié au contenu est possible. Ces options permettent, entre autre, de gérer le conflit lié à l’existence d’un conteneur ou d’un contenu dans la plateforme de destination. 6. Comparaison de collection de site Le déplacement de personnalisation d’une collection de site vers une autre peut se faire de manière incrémentale. Afin d’être sûr de ne porter que les éléments nécessaires et de ne pas écraser ceux qui ne doivent pas l’être, DocAve 6 Deployment Manager permet de comparer des éléments de collections de site, à différents niveaux : configuration, solutions, types de contenu, colonnes…et produire un comparatif visuel. Chaque élément différent entre la source et la destination apparait en ligne rouge (rose) avec une case à cocher à côté. Cela vous permet, en deux clics, d’inclure un élément qui n’existe pas dans la destination dans un plan de déploiement. Scenarii adaptés à DocAve Deployment Manager Scenario 1 Supposons qu’un client veuille ouvrir une offre collaborative interne sur SharePoint et que celui-ci ne dispose pas d’équipes de développements SharePoint et il ne prévoit pas d’en avoir, par contre il dispose d’une équipe IT généraliste. Pour ce scenario, la bonne approche serait de définir un modèle d’espace collaboratif (maquette), puis à partir d’un outil simple et intuitif, pouvoir répliquer ce modèle en maintenant toutes les personnalisations : charte graphique, sécurité, workflow… Ce client peut aussi proposer un environnement de test aux métiers (bac à sable) avant de passer des personnalisations en production. En général, les métiers oublient souvent la non-portabilité des données d’un bac à sable vers une production et c’est compréhensif, personne ne veut faire les choses deux fois, et parfois (voire souvent) on a du mal à se souvenir des personnalisations effectuées et dans quel ordre elles ont été effectuées. Scenario 2 Supposons qu’un client dispose d’une équipe de développement et qu’il veuille intégrer SharePoint dans son SI pour un usage purement collaboratif, avec des personnalisations (fonctionnalités) assez avancées. L’approche pour ce client serait de packager ses fonctionnalités sans pour autant créer des modèles de sites, pourquoi ? Pour être prévoyant et éviter de complexifier un futur upgrade de SharePoint car les modèles de sites natif SharePoint sont supportés par Microsoft lors de l’upgrade. Nous pouvons penser au SharePoint Feature Stapling, ou à un script pour ordonnancer la création d’une collection de sites, sauf qu’on retombe dans la situation de code supplémentaire à maintenir. Pour ce scenario, en plus des contraintes citées dans le scenario 1, il faudra minimiser les développements et s’assurer que les éléments personnalisés ne perdent pas leur état ; un fichier ghosté devra le rester même après la duplication d’une collection de site. DocAve Deployment Manager et Gouvernance SharePoint La clé de la réussite d’un déploiement SharePoint est la gouvernance. La gouvernance doit être pensée en amont du déploiement, avant même de débuter les personnalisations. Elle doit être une réflexion pragmatique et contextuelle à l’entreprise. Cette démarche nécessite l’industrialisation des process à différents niveaux en s’outillant. DocAve Deployment Manager est outil adressé à l’IT. Cependant AvePoint propose une solution dédiée aux utilisateurs finaux (métier) qui est DocAve Governance Automation. Governance Automation permet de proposer des catalogues de services aux utilisateurs finaux. Un des services proposé nativement dans Governance Automation permet l’automatisation de création de collection de sites, avec toutes les personnalisations embarquées en se basant sur un plan de déploiement DocAve 6 Deployment Manager. Governance Automation permet de proposer des catalogues de services autour de SharePoint pour des utilisateurs métier. L’IT et le métier modélisent les process de validation et les configurations nécessaires au service proposé. Les services Governance Automation sont au nombre de onze, je cite, par exemple le provisioning et la gestion du cycle de vie d’une collection de site, le clonage de permissions d’un utilisateur… Pour plus d’info sur Governance Automation ont disponible sur : https://www.avepoint.com/sharepoint-governance-automation