Intégration et déploiement

Lorsqu’on travaille avec des équipes en offshore, on se concentre avant tout sur les équipes de développement. Les équipes de test sont parfois oubliées, surtout si l’on ne fait pas la différence entre test et recette et qu’on place cette dernière chez le client, et il est rare que l’on pense aux équipes d’intégration et de déploiement. Les premières livraisons au client sont alors des casse-tête souvent cités en exemple des difficultés à travailler avec l’offshore. Les produits qui sont aujourd’hui développés en offshore ne se transportent pas aussi facilement qu’on le croit. Le temps des exécutables aisément transportables a pratiquement disparu. Les déploiements actuels sont multiserveurs. Ils demandent une compilation sur la plate-forme cible et s’accompagnent du déploiement et de la configuration de toute une série d’autres produits périphériques (base de données, serveur d’applications, message queueing, équilibreur de charge, etc.). Les premiers déploiements concernent des exécutables qui ne sont pas tout à fait finalisés et dont les procédures d’installation sont encore inexistantes ou tout juste émergentes. Ce qui fonctionne en offshore ne fonctionne pas nécessairement localement. Si l’on n’a pas prévu de créer une équipe d’intégration et de déploiement et que le produit nécessite une gestion de plate-forme avancée, on peut être certain que le déploiement de la solution sera perçu comme un problème. Ce problème s’envenime rapidement pour peu que le client s’agace de ne pouvoir appréhender le produit que ses chefs de projet en offshore disent fonctionner raisonnablement bien et qu’il perde confiance dans la qualité de la production en offshore. Si l’on reconnaît l’importance du déploiement et de la configuration de la plate-forme, on peut choisir de créer une équipe d’intégration et déploiement (ID) pour automatiser, configurer et déployer la production des équipes distantes. On peut aussi étendre leurs responsabilités pour assurer la supervision et l’administration des plates-formes, venant ainsi en support des équipes du client. 

Gestion des plates-formes 

La gestion des plates-formes inclut celle de tous les progiciels utilisés avec le produit. On y trouve bien sûr les systèmes d’exploitation, la base de données, mais aussi le Livre Offshore.book Page 281 Lundi, 21. février 2005 7:44 19 Intégration et déploiement Conduite de projets informatiques offshore 282 middleware (serveurs EJB, servlets, etc.) et, éventuellement, les progiciels fonctionnels sur lesquels s’appuie l’application. Ces produits demandent une gestion souvent assez lourde pour suivre leur configuration, assurer les optimisations, étudier les mises à jour des versions et préparer les migrations vers une nouvelle version de certains composants. L’équipe ID a pour responsabilité de configurer les couches techniques. Elle doit pour cela connaître précisément le fonctionnement interne de l’application afin de déterminer les services qui doivent être ouverts sur les serveurs. Par exemple, en maintenant la liste de tous les protocoles utilisés entre les composants et les serveurs, elle peut filtrer efficacement les échanges entre les serveurs en n’autorisant que les flux utiles, en améliorant du même coup le niveau de sécurité de la plate-forme. L’équipe ID a aussi pour responsabilité d’organiser la création des scripts d’assemblage des builds et de déploiement vers les différentes plates-formes cibles. Elle analyse les demandes d’évolution exprimées par le client et propose des plans d’action. Par exemple, si l’on veut que l’application, développée en Java et déployée jusqu’à présent sur des serveurs sous Windows, puisse être déployée sur une plate-forme sous Linux ou si l’on souhaite utiliser un serveur d’applications JBoss au lieu de BEA WebLogic, l’équipe ID étudie les problèmes potentiels et propose un plan d’action que le client choisira d’activer ou non. L’équipe ID s’assure de produire les notices de déploiement et de maintenance des applications, surtout lorsque l’hébergement est assuré par un tiers, qui est responsable d’un certain niveau de service et qui assure lui-même toutes les tâches de déploiement. Elle peut en outre assurer la supervision des plates-formes en vérifiant que l’application peut être administrée par les outils de supervision du marché. Elle peut proposer, par exemple, que le produit supporte des interfaces d’administration plus riches afin d’assurer une supervision plus fine. Assurer un service de supervision des plates-formes de production vingt-quatre heures sur vingt-quatre et sept jours sur sept n’est pas toujours facile et exige au moins cinq collaborateurs. Les équipes ID offshore peuvent assurer un tel service, parfois avec une flexibilité et pour un coût très intéressants. Comme nous le voyons, l’équipe ID n’est pas une équipe mineure dans l’organisation des réalisations offshore. Elle joue un rôle charnière au moment de la livraison et peut fournir une quantité de travail importante pour accompagner la solution une fois déployée, allégeant d’autant le travail des équipes du client. EN RÉSUMÉ L’équipe ID Une équipe dédiée à l’intégration et au déploiement en offshore (ID) complète harmonieusement les équipes de développement et de test en accompagnant les livrables jusqu’à fournir une solution déployée et recettable sur une plate-forme supervisée. L’offshore apporte à cette discipline fortement consommatrice de ressources de précieux avantages en terme de coûts et de flexibilité pour achever les travaux de construction de la solution. Livre Offshore.book Page 282 Lundi, 21. février 2005 7:44 19 Chapitre 14 – Intégration et déploiement 283 

Fondations techniques et procédures 

On peut décomposer en couches les éléments techniques sur lesquels s’appuie l’application, comme l’indique le tableau 14.1. Tableau 14.1. Fondations techniques Couche technique Fréquence des évolutions Intégration et déploiement SE (système d’exploitation) Service Packs assez fréquents et nouvelles versions rares – Étude et validation des nouvelles versions – Prise en compte des nouvelles possibilités – Évaluation des risques et proposition d’une méthode de migration sur les nouvelles versions ou d’autres SE Middleware, base de données, serveur d’applications (EJB), etc. Service Packs assez fréquents et évolution le plus souvent annuelle des produits Mêmes tâches que pour les SE Configuration et optimisation des systèmes d’exploitation et du middleware Évolutions très fréquentes lors des premiers déploiements et peu d’évolutions une fois le système stable – Étude des évolutions du produit – Recommandations pour faire un produit plus propre, par exemple en limitant les protocoles – Étude des performances du système et proposition d’évolutions Supervision Évolution rare des outils de supervision – Suivi des outils de supervision de la plate-forme – Création de nouvelles sondes ou d’interfaces pour mieux suivre le comportement de la plate-forme Scripts de création de builds et de déploiement Évolutions liées aux versions majeures ou aux nouvelles cibles technologiques – Création des scripts avec les fichiers de configuration des déploiements – Maintenance de ces scripts Versions majeures de l’application Évolutions le plus souvent annuelles ou rares – Mise à jour des scripts de déploiement. – Mise à jour des procédures de vérification du produit déployé Service Packs Périodicité assez courte de release des Service Packs Création des scripts de déploiement Patch et Hot Fix Périodicité aléatoire Création des scripts de déploiement Livre Offshore.book Page 283 Lundi, 21. février 2005 7:44 19 Conduite de projets informatiques offshore 284 En identifiant les différentes couches techniques utilisées par le projet, on peut en industrialiser la gestion par couche et éviter qu’elles deviennent des sources de dysfonctionnement lors des livraisons au client ou lors des déploiements chez les utilisateurs. Chacune de ces couches techniques peut être versionnée, et les évolutions peuvent être gérées selon des procédures similaires à celles des évolutions fonctionnelles. Toute demande de changement des fondations techniques doit suivre un workflow, à l’image des demandes d’évolution. L’équipe ID expose alors son analyse et les risques attachés aux changements. Certaines évolutions peuvent avoir un impact déstabilisant, qui peut exiger que l’on attende le moment adéquat afin d’en limiter les effets. Par exemple, si l’on gère une application de comptabilité, on peut éviter de mettre à jour une plate-forme vers la fin de l’année, moment où un grand nombre de sociétés clôturent leur exercice. L’organisation des fondations techniques est l’un des problèmes majeurs à résoudre lorsqu’on gère des projets avec une équipe offshore et que l’application est délicate à déployer. On néglige souvent de mettre en place les procédures qui conviennent pour gérer ces différentes fondations techniques. Sans cadre procédural, ces dernières diffèrent rapidement de celles du client, engendrant des différences de comportement du fait de la différence de versions ou de configurations d’éléments techniques. Chacune des couches techniques doit être associée aux procédures permettant de les gérer sans ambiguïté. Il est fréquent que le client ne parvienne pas à déployer les premières livraisons du partenaire. Après quelques tentatives d’assistance par téléphone et messagerie, le client demande à certains collaborateurs en offshore de venir chez lui pour l’aider. Une fois chez le client, ils forment des spécialistes pour assurer les déploiements ultérieurs. Ces spécialistes chez le client sont toutefois souvent occupés à d’autres tâches, comme le support technique pour les utilisateurs, ou assurent des déploiements d’autres applications ou d’autres tâches. Ils ne sont donc pas aussi performants que les collaborateurs du prestataire pour l’application développée en offshore.