L’automatisation : pas un luxe, une nécessité!

L’automatisation : pas un luxe, une nécessité!



Une question de profil et d’attentes

On distingue généralement deux types de profils dans l’écosystème SharePoint avec chacun, des attentes différentes :

  • D’un côté, les supers utilisateurs et autres administrateurs qui souhaitent répondre à un besoin ponctuel et limité de leurs utilisateurs via des interfaces simples. Le gain à automatiser ici reste ici relativement faible comparé à l’effort requis (temps et apprentissage). L’automatisation restera dans ce cas précis, un luxe.
  • De l’autre, les architectes et développeurs qui souhaitent livrer des solutions de qualité et qui doivent contrôler minutieusement la séquence de déploiement et s’assurer qu’elle sera reproductible à l’identique sur plusieurs environnements cibles. Ici, le besoin d’automatiser devient incontournable.

Une nécessité à planifier et à estimer

Soyons réalistes, il parait quasiment impossible d’envisager la réalisation d’une solution complète d’intranet d’entreprise sans automatiser tout ou partie de son déploiement. Imagineriez-vous avoir à faire des dizaines et des dizaines d’opérations manuelles, multipliées par le nombre d’environnements et ceci toutes les deux semaines pour déployer votre solution? Évidemment non.  Ainsi, que l’on veuille ou pas, automatiser devient donc une nécessité pour votre projet au même titre que les fonctionnalités à livrer initialement et doit être planifié et estimé en conséquence.

Un prérequis de la qualité professionnelle en SharePoint

L’automatisation représente le premier pas dans la qualité de votre solution. Une procédure déploiement parfaitement au point et éprouvée sur de multiples environnements vous assurera une base solide pour la suite de vos développements. Ainsi, lors de l’implémentation de chaque besoin de votre carnet de produit, ce que vous devriez implémenter en premier, c’est le moyen de déployer et configurer automatiquement.

Pas uniquement réservé aux clients, mais aussi aux développeurs

Automatiser ne signifie pas uniquement déployer votre solution dans les environnements de votre client. Vous pouvez très bien utiliser vos procédures pour vos propres machines vous assurant que tous les développeurs adoptent ainsi la même procédure et sont en mesure de réinstaller complètement l’application rapidement (très appréciable, lorsqu’un nouveau développeur arrive dans l’équipe et qu’il faut lui configurer un nouveau poste).

L’automatisation des configurations de SharePoint comme véritable gain

 Lorsque l’on parle d’automatisation, on a tendance à ne penser qu’uniquement aux solutions .wsp qui contiennent le code de notre solution. Toutefois, cette étape ne représente qu’une infime partie de notre procédure. Ce que l’on automatise en réalité, ce sont les configurations manuelles de SharePoint que l’on aurait faite dans l’interface et ceci dans un ordre bien précis.

Ainsi, dans cette étude de cas, l’aspect d’automatisation prend alors une place prépondérante. L’utilisation de la publication intersites fait intervenir une multitude de configurations SharePoint notamment au niveau des applications de service de recherche et de métadonnées gérées. Comme vous le verrez dans la suite de ces articles, il sera question de créer des sources de résultats, des règles de requêtes, des propriétés gérées de recherche, configurer la navigation par taxonomie, etc… et tout ceci au sein d’une séquence bien définie pour que cela puisse fonctionner. Réaliser ces opérations « à la main » nous prendrait très certainement un jour complet si ce n’est plus, sans compter le risque d’erreurs!

Le Framework Dynamite!, notre accélérateur de projets SharePoint et disponible pour vous

Depuis quelques années déjà, chez GSoft, nous développons notre propre Framework de développement SharePoint à l’interne surnommé Dynamite. Celui-ci a pour but principal de rendre générique, modulaire et réutilisable le travail issu de nos différents projets et mutualiser nos connaissances. Nous nous basons notamment sur les bonnes pratiques d’injection de dépendances en .Net.

Il s’agit pour l’instant d’un Framework uniquement « Server Side » pensé avant tout pour des solutions de types fermes avec une version dédiée à SharePoint 2010, et l’autre à SharePoint 2013, basées toutes deux toutes sur le framework d’injection de dépendance Autofac.  De plus, une trentaine de commandes PowerShell est également disponible pour vous aider à automatiser vos solutions.

Récemment, nous avons fait le choix de rendre public l’intégralité de ce Framework à travers GitHub. Ainsi, vous êtes maintenant libre de l’utiliser et d’y apporter vos modifications!

Par exemple, durant cette étude de cas, nous avons fait le choix d’investir massivement dans le développement de fonctions utilitaires et Cmdlets PowerShell liées à la publication intersites. Celles que nous avons utilisées pour créer notre procédure de déploiement sont toutes accessibles depuis GitHub et listées à la fin de chaque module.

Icône GitHub

Dynamite-logo4

Par exemple, durant cette étude de cas, nous avons fait le choix d’investir massivement dans le développement de fonctions utilitaires et Cmdlets PowerShell liées à la publication intersites. Celles que nous avons utilisées pour créer notre procédure de déploiement sont toutes accessibles depuis GitHub et listées à la fin de chaque module.

PowerShell et C# pour le meilleur des mondes

Lorsqu’il s’agit d’automatiser les configurations de SharePoint, plusieurs possibilités s’offrent à vous:

  • Utiliser du code C#, déployé à travers une solution *.wsp et activé via des features SharePoint. Ce type de déploiement est généralement réservé aux configurations limitées au niveau d’un site ou d’une collection de sites.
  • Utiliser PowerShell.

Pour notre part, nous avons choisi d’utiliser au maximum PowerShell et créer nos propres fonctions et Cmdlets d’automatisation. Pourquoi? Parce-que PowerShell est un langage de Scripting puissant et flexible adapté au séquencement d’actions.

La plupart de ces commandes sont en revanche écrites directement en C# dans notre Framework. Le but: favoriser la réutilisation dans un contexte uniquement .Net et garantir une plus grande robustesse du code. Beaucoup de fonctions demeurent cependant uniquement en PowerShell soit parce que le portage en C# s’avérait superflu ou bien que nous n’avons pas eu le temps de faire l’équivalence). Notre approche se résume de la manière suivante:

Notre stratégie d'automatisation Dynamite!

Diviser pour mieux régner

Le fonctionnement de nos Cmdlets et fonctions respecte globalement toujours le même schéma : une commande ou fonction est associée à un XML de configuration et traite d’une notion bien définie:

 Principe de nos Cmdlets

Ainsi, dans nos procédures de déploiements, nous préférons avoir beaucoup d’étapes très granulaires, plutôt qu’une seule grosse étape basée sur un fichier de configuration unique.

Avantages

  • Identifie clairement le périmètre de chaque Cmdlet ou fonction facilitant les tests.  Par exemple, la Cmdlet « New-DSPQueryRules » ne s’attachera qu’à la création de règles de requêtes et pas autre chose.
  • Donne une flexibilité dans la mise en place de la séquence de déploiement selon les projets.

Inconvénients

  • Génère des doublons dans l’information de configuration. Par exemple, il est très probable que la même URL de votre site SharePoint se retrouve dans deux fichiers XML de configuration différents avec des traitements différents. Cependant, pour nuancer ce point, nous avons élaboré un système de « templating » basé sur des « tokens » selon les environnements:

Notre stratégie de templating de configuration selon les environnements

Notre commande Update-DSPTokens se contente de scanner tous les fichiers *.template de la solution et remplacer les valeurs de tokens « [[…]] » correspondant à ceux du fichier de configuration de la machine courante.

  • Peut paraitre lourd à première vue. Pour de gros projets, le nombre de fichiers de configuration peut vite devenir conséquent. A titre d’exemple, la procédure de déploiement pour l’intranet complet dont cette étude de cas s’inspire comprend 35 étapes de PowerShell pour quasiment autant de fichiers de configuration XML

En résumé, automatiser c’est…

  • Tester vos processus de déploiements très tôt dans le projet, même avec peu de fonctionnalités et ainsi éviter beaucoup de « SharePoint » surprises.
  • Avoir une équipe de développement beaucoup moins stressée lors des déploiements en environnement client car utilisant la même procédure pour ses propres machines.
  • Avoir une équipe ou chacun est en mesure d’effectuer un déploiement chez le client (pas d’expert attitré).
  • Ressentir certaine fierté de pouvoir aller se chercher un café en sachant que lorsqu’on reviendra, l’application sera intégralement déployée et fonctionnelle.
  • Ne pas avoir à lire (ou rédiger, encore pire) un manuel de 100 pages ou figurent 65 étapes manuelles à réaliser.
  • Accélérer grandement l’intégration de nouveaux développeurs dans l’équipe.
  • Uniformiser les pratiques entre tous les membres de l’équipe de développement.
  • Investir pour vos futurs projets.

Quelques recommandations suite à notre projet

  • Déployer le plus tôt possible sur les environnements finaux. Si il y a bien une chose dont nous sommes sûrs, c’est qu’il n’existe aucun environnement SharePoint identique, même à version égale (votre machine de développement ne reproduira JAMAIS l’environnement de votre client). Vous vous éviterez bien des surprises en anticipant très tôt ces problématiques.
  • N’hésitez pas à passer du temps sur l’aspect d’automatisation et limiter les actions manuelles. Même un développeur confirmé est de faire des erreurs d’inattention. Cette étape vous sera de toute façon bénéfique pour vos futurs projets.
  • Gardez un manuel de déploiement synthétique qui indique clairement vos prérequis à celui-ci notamment:
    • La configuration du magasin de termes (notamment les langues disponibles).
    • Les permissions à avoir pour les comptes d’installation et autres.
    • Les services à démarrer (ForeFront Identity Manager Service notamment).
    • Les entrées DNS à avoir.
    • Etc…
  • Planifiez votre déploiement à chaque Sprint pour faire vos démos (Sprint Review) sur les environnements de votre client et non sur une machine de développement.

+ There are no comments

Add yours