ALM – Industrialisation des développements CRM – Architecture technique de développement


Un des aspects important de la phase de conception est la mise en œuvre d'une plateforme de développement.
Celle-ci doit être optimisée de manière à supporter tous les flux d'activités des développeurs. (nous détaillerons cet aspect dans un prochain billet)

Qui travaille sur la plateforme de dév ?

Sur une plateforme de développement, nous retrouvons différentes populations :

  • Customizers : Ils réalisent les paramétrage et personnalisations de l'interface CRM (création d'entités, de champs, de formulaires, de vues, de règles métier …). Son interaction avec le système est importante, il sollicite des processus qui ralentissent la plateforme (ex : publication des personnalisations).
  • Développeurs : Ils développent des composants destinés à étendre le fonctionnement standard du produit (ressources web, plugins, workflows …)
    Leur interaction avec la plateforme est très forte et rend le comportement du système instable :
    • Débogage pouvant stopper les processus et bloquer l'interface
    • Processus non finalisés provoquant des erreurs
  • Testeurs : Ils vérifient le bon fonctionnement de la solution mais également la performance des processus.
  • Release Managers : Ils préparent les packages et réalisent des déploiements afin de vérifier les étapes nécessaires à la procédure d'installation.

Et quels sont les impacts ?

Ces différents acteurs interagissent sur des axes différents qui rend leur cohabitation difficile voire impossible.
En terme d'organisation, il est donc nécessaire d'envisager la décomposition suivante :

  • Customizers : Ils doivent travailler en amont, avant les développeurs. 
    Ils peuvent être répartis sur différents serveurs CRM Web pour limiter les effets de ralentissement.
    Ils doivent travailler sur des solutions contenant des composants différents représentant les différents domaines fonctionnels.
  • Développeurs : Ils interviennent après les customizers. Idéalement, ils doivent travailler sur des serveurs séparés.
    Si ils sont nombreux, l'idéal est de leur dédier une machine virtuelle disposant de tous les composants nécessaires.
    Ainsi ils peuvent héberger leur propre environnement de développement, ce qui leur confère une certaine mobilité.
    L'avantage de la virtualisation est la capacité de restaurer un environnement complet à un instant T en un simple clic, facilitant ainsi les retours en arrière en cas de problème.
  • Testeurs : Ils interviennent après les développeurs. Il est important qu'ils puissent travailler sur un environnement isolé des activités de développement.
    En effet, l'environnement doit être stable pour permettre de valider le fonctionnement de la solution mais également d'évaluer les performances.
  • Release Managers : Ils interviennent à toutes les étapes de conception pour déployer les environnements nécessaires.
    Il est nécessaire de leur fournir les binaires à jour pour qu'ils puissent

Comment structurer la plateforme pour assurer les différentes activités ?

Cela nécessite donc de définir une architecture tenant compte de ces différentes problématiques mais de limiter les efforts en déploiement et maintenance.
Donc si l'on avance par étape :

  1. Les customizers doivent travailler sur un même environnement CRM mais sur des serveurs Web différents.
    Ainsi, avec 2 customizers, on peut envisager la topologie suivante :clip_image001[1]
  2. Les développeurs doivent être sur des environnements isolés.
    Ainsi avec 3 développeurs, l'idéal est d'héberger leur environnement de développement dans une machine virtuelle en synchronisant leur développement avec TFS :clip_image002[1]
  3. Les testeurs doivent travailler sur un environnement stable.
    Supposons que nous ayons 2 testeurs, cela signifie qu'ils doivent travailler sur un environnement CRM indépendant :clip_image003[1]

Tout ça c'est très bien, mais quelle est l'architecture globale ?

Nous avons vu comment chaque type de population interagissait avec le système et les contraintes imposées à l'architecture mais à présent il nous manque la vision d'ensemble.

En effet, comment réunir toutes ces composantes et faciliter leur interaction ?

Si l'on réunit simplement les précédentes topologies nous obtenons :

clip_image004[1]

Il reste donc à répondre aux questions suivantes :

  1. Comment synchroniser le travail réalisé sur l'organisation 1 vers les VM de développement ?
    En effet, les développeurs ont besoin des personnalisations pour travailler.
    Par exemple, si le modèle de données évolue, les modifications doivent pouvoir être transmises rapidement sur les VM des développeurs.
  2. Comment déployer les développements depuis les VM vers l'organisation 1 ?
    Il existe des dépendances entre les développements et les personnalisations comme par exemple les liens entre les formulaires et les ressources Web.
  3. Comment synchroniser la dernière version stable de la solution sur l'organisation 2 ?
    Les testeurs ont besoin d'avoir l'ensemble des personnalisations et développement mais avec la garantie qu'ils soient à jour et stables.

Toutes ces questions trouvent une réponse avec TFS pour plusieurs raisons :

  • Grâce à l'outil SolutionPackager il est possible de synchroniser les personnalisations de CRM dans TFS.
    Ce qui permet de :
    • Faciliter la gestion des versions applicatives au travers des branches TFS
    • Suivre et comparer les modifications des entités CRM au travers de l'historique fourni par TFS
    • Gérer les conflits lorsqu'un même élément est modifié par 2 personnes
  • Avec TFS il est possible de faire de l'intégration continue, autrement dit, on peut automatiser des taches autour des sources et ainsi :
    • Déclencher des builds automatisés lors de l'archivage des modifications des customizers / développeurs afin de générer un fichier contenant la solution CRM à jour
    • Déclencher des builds régulières pour vérifier la qualité des développements (tests unitaires) et les déployer sur un environnement de test
  • Et aller plus loin :
    • Provoquer l'injection de données de référence sur un environnement cible
    • Réaliser des Coded-UI Tests afin de confirmer la non-régression sur l'environnement de tests

Au final, TFS est bien au centre de notre architecture, cela devient notre référentiel des personnalisations et développements sur CRM.

En savoir plus :

 

Les articles de la série “ALM - Industrialisation des développements CRM” :

  1. Définition de l'équipe projet
    Quels sont les différents rôles des membres d'une équipe de développements ?
  2. Team Foundation Server (TFS)
    Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
  3. Organisation des développements
    Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
  4. Architecture technique
    Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
  5. Solution de développement CRM
    Qu'impliquent ces développements et comment les structurer ?
  6. Activités de développement et outils
    Que font les développeurs ? Comment minimiser leur effort ?

Les équipes Microsoft Services se tiennent prêtes à vous accompagner tout au long de la mise en place de votre outil CRM. Pour en savoir plus, n'hésitez pas à nous contacter, via notre formulaire de contact ou à l'adresse : servicesfr@microsoft.com.

Comments (0)

Skip to main content