6 étapes clés pour optimiser vos enchainements de déploiement continu

Quand des équipes mettent en place des pipelines de déploiement continu, elles partagent toutes les mêmes objectifs. Elles veulent rationaliser leurs processus pour produire de meilleurs logiciels. Mais comment s’y prennent-elles ? Quels sont les pièges à éviter ? Le point.

C’est la première étape pour faire progresser vos pipelines existants vers un stade plus avancé. Vous avez cartographié votre pipeline; à présent, il vous faut un modèle bien plus détaillé pour savoir comment le code applicatif va circuler au gré des étapes du processus. Identifiez les possibles goulets d’étranglement, où vous pourrez souhaiter remonter la boucle et où prévoir des contrôles pour vérifier que la qualité est au rendez-vous. Déroulez l’enchaînement d’un bout à l’autre du processus, des étapes de développement, d’assurance-qualité et de pré-production à celles de production. Comme le dirait Jez Humble*, « modélisez le flux de valeur ».

2- Mesurez votre pipeline

Maintenant que vous avez modélisé votre enchaînement, mesurez tout. Examinez chaque étape et identifiez les goulets d’étranglement. Comme vous avez modélisé les étapes, vous pouvez générer des métriques après chacune d’entre elles. Mesurez la vitesse et la qualité des builds. Testez tout. Le principal objectif consiste à réaliser autant de tests que possible dans le délai le plus court possible. Si vous ne disposez pas encore d’un processus de test automatisé, c’est le moment d’y passer.

3- Apprenez aussi vite que possible

D’emblée, on pense que le mieux est de créer un enchaînement avec un flux uniforme du début à la fin. Or ce n’est pas vraiment le cas. On souhaite exécuter les étapes de bout en bout aussi efficacement et aussi rapidement que possible. Mais il faut prévoir plus de temps pour les tests et plus de possibilités de redémarrage du processus au plus tôt pour s’assurer que les objectifs sont tenus à chaque étape. Si quelque chose doit casser, il vaut mieux que ça arrive vite. Les portions tardives du pipeline sont celles où les possibilités de panne sont les plus nombreuses. Si un développeur opère un changement, il doit savoir dans les cinq minutes si quelque chose ne fonctionne pas correctement. Il peut alors passer à l’étape suivante. Les tests les plus lourds peuvent être réalisés toutes les 15 minutes. Dans certains scénarios, il est possible de paralléliser les tests dans le pipeline, voire d’exécuter ces tests en parallèle d’autres étapes du pipeline.

4- Evitez les chemins critiques longs

Si vos chemins sont trop longs, vous risquez de créer une situation où des builds sont en attente inutilement. Si vous pouvez découper votre projet en portions, le processus sera finalisé plus rapidement. Si vos tests automatisés durent plusieurs jours, c’est trop long. Pensez à entrecouper la séquence par des temps de feedback.

5- Trouvez le moyen d’exécuter des étapes en parallèle

Pour gagner du temps et de l’énergie, exécutez les builds en parallèle. Il est inutile de faire perdre du temps aux gens quand des machines peuvent exécuter des tâches en arrière-plan. L’équipe de développement peut déclarer que tout a été fait pour optimiser les processus la concernant, mais le reste de pipeline prendra toujours beaucoup de temps. Toute l’organisation n’a pas encore analysé et amélioré son pipeline de déploiement continu.

Imaginons qu’il reste trois jours entre le commit de code et la fin d’un test. Si le test échoue à l’étape deux, vous pouvez faire redémarrer le build au second jour, à la deuxième heure, près du point de la défaillance. Ne perdez pas de temps à refaire les mêmes tests. Choisissez le point de reprise à partir duquel repartir. Par exemple, si quelque chose se passe mal au niveau d’un test, le testeur doit pouvoir décider où redémarrer le test.

6- Ne tombez pas dans l’excès d’automatisation

Des problèmes peuvent se produire en cours de vérifications sans que la personne qui opère le changement puisse les répéter. Par exemple, si vous avez un processus de déploiement continu configuré pour un site web dynamique, et qu’un test échoue au bout de deux heures, un testeur devrait pouvoir partir du message d’erreur et faire ses propres tentatives. Il faut configurer les pipelines pour qu’ils acceptent l’intervention humaine. Tous les avantages attendus d’un pipeline peuvent être annulés dès que des tests aboutissant à un échec obligent à redémarrer un processus donné de zéro.

Pour conclure, les pipelines de déploiement continu sont comme des cultures agricoles. Vous ne pouvez pas les semer et les oublier ; il faut les cultiver le temps qu’ils prennent de la vigueur et deviennent plus robustes pour donner de meilleurs résultats. Ces bonnes pratiques peuvent aider vos équipes à produire de meilleurs logiciels, plus rapidement, avec davantage d’efficacité et de façon plus stratégique. Et surtout, l’entreprise en retirera davantage de valeur. Jenkins Workflow aide à créer facilement ces types de pipeline de déploiement continu avec Jenkins pour délivrer plus rapidement de meilleurs logiciels.

*Co-auteur avec David Farley de l’ouvrage de référence « Continuous Delivery », paru en Juillet 2010