Le déploiement continu

 

Une application web et une application mobile sont immédiatement disponibles pour vos utilisateurs. Il leur suffit d’une URL pour avoir accès à la version la plus récente. C’est un changement de paradigme qui a bouleversé des habitudes de fonctionnement qui demandaient du temps pour préparer un produit qui devait être “fini”. C’est l’exemple du journal physique. Et c’est une méthode de travail qui reste encore très présente dans notre organisation.

Vos applications digitales, vous pouvez les mettre à jour dès que nécessaire. L’échelle de temps pour proposer de nouveaux services à vos clients s’en trouve fortement réduite. On a même la possibilité de tester l’intérêt économique d’un nouveau service sans que celui-ci ne soit vraiment fini.

Et pourtant, il y a des freins, notamment d’un point de vue technique :

• Comment faire en sorte qu’un déploiement ne soit pas un saut dans l’inconnu ?
• Qu’est-ce qui vous empêche de mettre en production de nouveaux développements le vendredi ?
• Pourquoi faut-il des semaines pour voir arriver en production la correction d’une faute d’orthographe ?

Quels sont les outils et usages qui vous permettront de mettre en place une pratique effective de l’adaptation continue ?

1 Comment bien gérer son code ?

1.1 Paralléliser et prioriser

Les outils de gestion du code comme Git permettent de travailler plus sereinement en équipe car tout est centralisé à un même endroit. Mais ce n’est qu’une petite partie de l’intérêt de ces outils. Le système de branches permet de fusionner une nouvelle fonctionnalité uniquement quand elle est terminée. Chaque fonctionnalité doit donc être développée indépendamment des autres, et l’ordre de mise à disposition dépend de vos priorités et de leurs disponibilités.

1.2 Automatiser un premier niveau de qualification

Le développement informatique est une science qui bénéficie d’un historique qui lui permet de disposer d’une base de connaissances très vaste. Des normes existent, il n’y a pas de raison de ne pas en utiliser. De plus, les outils de développement permettent d’appliquer eux-mêmes des modifications dans un code existant pour respecter ces normes. En cas d’impossibilité, ils peuvent alerter sur les problèmes identifiés. Même s’ils ne sont pas parfaits, se passer de ce premier niveau d’aide est un risque d’erreur une fois en production.

1.3 La relecture de code est aussi un moyen de progresser

Même si l’automatisation des outils de développement fait régulièrement des progrès, on ne peut que recommander une relecture par un pair. L’objectif est de valider que les moyens qui ont été mis en place correspondent à ce qui avait été défini, avec des méthodes de développement qui sont cohérentes avec les connaissances et habitudes du reste de l’équipe. Vous vous assurez ainsi que l’évolution du code se fait de telle façon que son entretien ne sera pas trop coûteux. Une autre personne de l’équipe pourra s’y retrouver. Et c’est ce qui fait monter en compétence une autre personne qui est encore en phase d’apprentissage.

1.4 L’intelligence artificielle, une nouvelle aide

Les outils d’aide à l’écriture de code ont connu une révolution technologique qui permet aujourd’hui de les utiliser comme une aide à la programmation. Les IA prennent en compte le contexte de ce que vous êtes en train d’écrire pour proposer des suggestions qui sont du temps gagné. Même s’il ne faut pas leur faire confiance de façon aveugle, il n’est pas recommandé de les ignorer complètement.

2 Comment intégrer une analyse de qualité automatisée ?

2.1 Intégration continue

Avant de rejoindre la base de code principale, tout nouveau code peut passer par plusieurs phases de qualification. Ces tests sont automatisés. Aucune action manuelle ne doit être faite pour être certain qu’ils soient toujours exécutés. On peut alors choisir ce qui se passe en cas de non respect des normes cibles. On peut se contenter d’une alerte, ou bloquer la fusion du nouveau code.

2.2 Exécution des tests unitaires

Le test unitaire a pour objectif d’assurer la non régression d’une évolution du code. Ils sont souvent assez éloignés de l’aspect fonctionnel de votre solution. En effet, ils ont pour objectif de tester des éléments atomiques qui gèrent une partie seulement de l’ensemble d’une fonction. Mais s’ils sont en échec, c’est toute la fonctionnalité qui est impactée. Il faut donc s’assurer, quand une évolution doit être fusionnée, que ces tests sont toujours respectés. Avec cette méthode, on diminue fortement le risque de régression.

2.3 Outils d’analyse de qualité de code

Une base de code peut rapidement devenir très importante, avec des centaines de milliers de lignes de code. Cette volumétrie n’est pas compatible avec une revue manuelle. C’est pourquoi il est conseillé d’utiliser des outils qui vont faire un exercice de relecture en mettant en évidence des malfaçons par rapport aux bases de connaissances sur les langages utilisés. Ces outils vont par exemple mesurer :

• les bouts de code qui sont présents plusieurs fois, ce qui complique l’entretien et la correction (il faut le faire plusieurs fois),
• la complexité, qui impacte négativement le travail de maintenance par une autre personne qui n’est pas à l’origine de l’écriture initiale,
• les mauvaises pratiques de sécurité, qui peuvent se retrouver en production.

Ces outils conservent l’historique de l’évolution des indicateurs. C’est important pour savoir si, au fil du temps, on augmente les risques associés à des mises en production. L’investissement sur du travail de mise à niveau devient plus naturel quand on sait pourquoi on le fait et quand on peut mesurer que l’objectif a été atteint.

3. Pourquoi et comment mettre en place des tests automatisés ?

3.1 Les APIs

L’écosystème des applications web repose sur des APIs qui ont une importance critique pour le bon fonctionnement de vos services. Si vous êtes responsable d’APIs, vous êtes redevable d’un niveau de qualité élevé pour ne pas impacter le bon fonctionnement des applications qui en dépendent. Même si vous avez déjà mis en place des tests unitaires pour limiter les risques de changements imprévus, nous vous conseillons aussi de mettre en place des tests automatisés qui vont utiliser vos APIs et assurer que des scénarios représentatifs de leurs usages restent fonctionnels. Cette couche supplémentaire d’assurance vous fera gagner en qualité.

3.2 L’interface utilisateur

Il est possible de piloter programmatiquement un navigateur web ou un mobile, et de lui faire exécuter un scénario qu’il peut reproduire à la demande. Il va se comporter comme un utilisateur, c’est-à-dire utiliser tous les éléments graphiques qui permettent d’interagir avec l’application (remplir un formulaire, manipuler des éléments avec la souris ou le doigt, …).

Ces tests ne peuvent généralement pas être exhaustifs, car ils sont longs à exécuter et chronophages à écrire. Mais il est toujours possible de tester des chemins critiques avec un effort mesuré. Ils ont alors une très forte valeur ajoutée. S’ils se passent bien, le risque qu’un déploiement coupe un service devient minimal.

3.3 Conditions de reproductibilité

Pour pouvoir faire des tests automatisés, il faut être en mesure de leur mettre à disposition un environnement dans lequel ils pourront toujours faire le même test. Si on prend l’exemple d’un site ecommerce, certains produits doivent toujours être disponibles, voire toujours en solde. Il existe plusieurs stratégies pour y arriver :

• modifier la base de données de référence,
• modifier le comportement des APIs utilisées,
• permettre à l’interface test d’éviter des points de blocage (comme le captcha par exemple).

4 Comment mettre en place des déploiements automatisés ?

4.1 Scripter tout le processus de mise en production

Déployer du code en production est un ensemble de manipulations qui doivent être faites en respectant un ordonnancement et des commandes qui sont très précises. L’erreur est à proscrire car l’impact est quasi systématiquement une perte du service. Quand l’opération est manuelle, elle peut aussi être chronophage, donc bloquer la disponibilité d’une personne qui doit de plus avoir des connaissances bien précises.

Pour ces raisons, il est préférable d’automatiser toutes ces étapes, ce qui permet non seulement d’assurer qu’elles se reproduisent tout le temps de la même façon, mais aussi qu’elles s’arrêtent dès qu’un dysfonctionnement est détecté.

Enfin, il ne sera plus nécessaire de faire appel à un technicien dédié pour chaque déploiement.

4.2 Maîtriser le rollback

Le risque d’erreur n’étant jamais nul, il est nécessaire d’anticiper une réaction dans le cas où un problème apparaît. Le plus classique est de s’équiper pour revenir en arrière si la correction est trop longue. C’est le rollback. Comme pour le déploiement, s’il est automatisé, on est équipé pour limiter l’impact engendré par la mauvaise mise en production.

4.3 Ouverture graduelle au public

Une application web ou mobile peut être mise à disposition des utilisateurs à un rythme maîtrisé. On n’est pas obligé d’ouvrir à tout le monde au même moment. On peut le faire en deux étapes par exemple, avec 50% des utilisateurs qui ont accès aux nouvelles fonctionnalités pendant que le reste continue à avoir accès à l’ancienne version. Le processus de déploiement doit le prendre en considération. Même après tous les tests qui ont été réalisés, si c’est lors du déploiement qu’on se rend qu’un problème est présent, on peut le faire dès le démarrage, quand peu de monde y a accès. On limite l’impact client.

5 Quels outils de surveillance et d’alertes mettre en place ?

5.1 L’observabilité

Est-ce que vos tests sont suffisants pour garantir que l’application fonctionne correctement pour tout le monde ? C’est impossible de répondre à cette question sans observer l’intégralité de ce qui se passe sur votre environnement. Les outils d’analyse du comportement utilisateur (comme Google Analytics) peuvent permettre de répondre en partie à cette problématique, mais ils ont comme principaux manques de ne pas être en temps réel, et surtout de ne pas être équipés pour proposer des alertes par défaut.

5.2 Des outils ouverts

Pour surveiller vos applications, vous pouvez mettre en place des outils qui vont récupérer l’ensemble des traces générées par vos serveurs, les agréger dans un endroit centralisé, et enfin vous permettre de les visualiser. Des tableaux de bord préconçus peuvent aussi être mis en place pour les briques logicielles qui font référence. La communauté Open Source en met beaucoup à disposition. Enfin, ils permettent la mise en place de systèmes d’alertes, qui peuvent être des mails, des outils de messagerie instantanée, ou des plateformes de gestion des incidents. Vous serez ainsi alertés avant de voir l’impact sur vos visiteurs dans votre outil analytique.

5.3 L’APM (APplication Monitoring)

En dehors des outils Open Source, de nombreuses solutions permettent de simplifier la mise en place d’une observabilité globale, mais surtout de bénéficier d’alertes automatiques. Grâce à des outils statistiques, ces solutions peuvent identifier des comportements qui dévient de ce qui est généralement observé. Et dans le cas où ces déviations ont un impact négatif pour vos utilisateurs (comme par exemple la dégradation des temps de réponse), vous pouvez être alertés sans avoir fait aucune configuration.

6 Quelles sont les potentialités business du déploiement continu ?

6.1 La réactivité

Dans un écosystème digital où la concurrence est rude, être capable de réagir rapidement est un point important de votre activité. Si votre service ne propose pas une expérience satisfaisante, il suffit d’un clic pour aller chez un concurrent. C’est pourquoi il est conseillé de choisir une approche qui vous permet de déployer rapidement une amélioration qui sera bénéfique pour votre activité.

6.2 La maîtrise des investissements

Vous savez déployer rapidement et sereinement des évolutions de votre activité ? Alors vous pouvez tester des évolutions qui sont incomplètes par rapport à votre vision cible, mais qui apportent déjà de la valeur ajoutée. Et selon la façon dont elles sont accueillies et utilisées, vous pouvez adapter votre stratégie pour tenir compte de ce que vous avez appris. Vos investissements sont donc mieux rentabilisés car vous évitez des travaux qui ne trouveront pas leur public.

En conclusion

L’adaptation continue, c’est pouvoir mettre en production tout incrément de la solution dès qu’il est prêt. Cette mise en production doit pouvoir se faire en limitant au maximum le risque induit par tout changement d’une plateforme qui jusqu’ici fonctionne correctement. Et dans le cas où un problème apparaît, il faut être averti pour pouvoir réagir.

C’est sur trois piliers que Kaliop a de l’expérience et de le l’expertise. Nous nous reposons dessus sur les projets que nous réalisons. Nous pouvons vous accompagner pour le mettre en place dans votre organisation.