Nos équipes ont beaucoup avancé sur les problématiques d’intégration continue, et notamment les tests de non régression automatisés. Les tests d’intégration et les tests unitaires nous rendent désormais très confiant sur la qualité de nos versions logicielles produites à chaque itération. Avec du recul, le fait d’avancer en cycle court et de disposer de ces tests a transformé la manière de travailler de l’équipe ainsi que celles qui sont connectée au cycle de vie de l’application (support, équipes projet, etc.). Les clients, de plus en plus nombreux, ont la possibilité de tester plus rapidement les dernières versions intermédiaires ou officielles. Les limites de ces avancées se situent maintenant au niveau du déploiement qui reste une intervention manuelle. Pour faciliter la mise en service des nouvelles versions logicielles, nous étudions les mécanismes de la livraison et du déploiement continu. Voici les pistes sur lesquelles nous travaillons:
I. Les cycles courts donnent le rythme à l’équipe pour s’organiser afin de produire une nouvelle version du logiciel en quelques jours / semaines. Les tests unitaires et d’intégration sont indispensables pour garantir la non régression et la conformité durant ces cycles.
II. L’intégration continue doit être privilégiée. Tous les développements sont effectués sur la même branche, même les évolutions complexes (parfois plus longues que la durée d’un cycle) en utilisant le concept de “Branch by abstraction”.
III. La migration de configuration et de données pouvant s’effectuer d’une version n-x à n, il est nécessaire de prévoir un mécanisme incrémental permettant de mettre à jour n’importe quelle version des configurations et des données vers la dernière.
IV. La mutualisation des clients au sein d’une même plateforme simplifie beaucoup l’architecture globale du système. Il ne s’agit plus d’assurer un environnement de production à chaque client mais de regrouper tous les clients sur un même environnement. Ainsi, cette plateforme unique sera beaucoup mieux maîtrisée (mais aussi plus critique) qu’un parc hétérogène d’environnements sur lesquels la maintenance est effectuée unitairement.
V. Un deuxième environnement de production limite les contraintes de déploiement. Cet environnement prend le relais si le premier est mis en défaut. La mise à jour de l’un des environnements n’implique pas l’arrêt du service pendant la maintenance puisque l’autre est toujours actif. Si le nouvel environnement présentait des défauts, il serait possible de revenir facilement sur l’environnement qui n’a pas encore migré. Martin Fowler aborde cette stratégie de déploiement dans son article sur le Blue-green deployment.
VI. Tous les clients n’ont pas les mêmes besoins et exigences sur la qualité du logiciel. Certains acceptent de migrer lorsque la nouvelle version officielle a été largement éprouvée, d’autres sont prêt à utiliser une version non officielle, toujours en développement, tout en sachant qu’il y a des risques d’instabilité. Afin de contenter ces différents clients, il est possible de proposer des abonnements aux canaux de “build” en fonction de leur profil. Le site “MakeUseOf” explique comment sont utilisés ces canaux pour le produit Google Chrome.
VII. Dans certains cas, une architecture hybride peut être utilisée afin de répondre à des besoins de production mais aussi de prototypage. Par exemple, cette architecture est capable d’aiguiller la demande client vers un environnement de type production ou prototype, sans que le client ait à s’en préoccuper. L’aiguillage suit en principe des règles simples basées sur des types de produit ou sur des demandes utilisateurs identifiés comme beta-testeurs.
VIII. La chaine de déploiement doit être suffisamment optimisée pour garantir flexibilité et réactivité. L’article “Deployment pipeline anti-patterns” souligne les effets négatifs d’une chaîne insuffisamment parallélisée et trop contraignante. Il propose d’établir un chemin critique en fonction des taches automatisées et de paralléliser un maximum celles qui sont manuelles.
IX. La sécurisation des serveurs, des données et des traitements automatiques est cruciale. Il est nécessaire de monitorer les serveurs impliqués dans le procédé de livraison continue. De même, les données de tests et les scripts utilisés dans le pipeline de déploiement doivent également être protégés.
X. Le déploiement continue repose avant tout sur les personnes: organisation, planification, rédaction des scripts, choix des outils et de leur maintenance, documentation, transfert de connaissance, etc. Il est nécessaire de considérer le procédé de déploiement continue comme un véritable projet avec une équipe et des rôles parfaitement identifiés.
Comment enclencher tout ça, par quoi commencer? En fait, il ne s’agit pas de commencer, mais plutôt de continuer: nous avons une équipe devenue expérimentée sur les différents éléments de la chaîne d’intégration continue, elle a pris l’habitude de rendre automatisable les choses qui valent le coup de l’être tout en mettant l’accent sur la simplicité. La livraison continue nous apparaît un peu comme le prolongement, avec des phases de prototypage, de premières réussites et de consolidation.
