Pour optimiser les flux dans votre pipeline et accélérer les délais de mises en oeuvre  de vos changements de code.

De nombreuses organisations IT partagent aujourd’hui un même objectif : étendre leur démarche de continuous delivery, en accroissant leur agilité et en adoptant les bonnes pratiques issues du DevOps. L’un de leurs principaux défis réside dans leur capacité à automatiser et sécuriser les flux de modifications de code, du commit à la mise en production, et ce quel que soit le nombre de builds dans le pipeline. Autrement dit, à « scaler » leur continuous delivery.

Car la force du continous delivery, qui consiste à raccourcir les cycles de production, peut aussi parfois devenir sa faiblesse : lorsque le volume de tests de builds simultanés devient trop important (des milliers de tests unitaires, d’intégration, fonctionnels et de performance, pour chaque commit), les temps d’exécution augmentent et les goulots d’étranglement se multiplient. Il arrive ainsi que plus d’une journée soit nécessaire pour que le commit d’un développeur atteigne la phase de tests de performance. Un délai qui n’est évidemment pas tolérable dans une démarche agile.

Comment éviter cet écueil, et permettre d’optimiser les flux dans le pipeline ainsi que les délais de mise en oeuvre ? Deux solutions complémentaires peuvent être envisagées :

1. Capitalisez et parallélisez autant que possible

Par exemple, en réutilisant les mêmes scripts Selenium pour les tests de charge et de performance que pendant la phase de tests fonctionnels. Il suffit de générer plusieurs conteneurs Dockers sur AWS (ou n’importe quel autre fournisseur de services Cloud) et d’exécuter les tests Selenium en parallèle. Cela évite de recréer les mêmes scenarii dans des outils de tests différents. Et cela vaut autant pour un test de charge unique sur un seul build, que pour plusieurs tests sur plusieurs builds.

2. Anticipez les problèmes de performance

L’objectif étant d’identifier les problèmes de performance plus tôt dans le pipeline et de n’autoriser ensuite que les « bons builds ». Il s’agit en fait de convertir automatiquement les tests fonctionnels en tests de performance, via des indicateurs clés d’architecture (nombre d’objets par page, nombre total d’octets transférés, nombre de requêtes SQL exécutées, etc.), de performance et de scalabilité, capturés pendant l’exécution de tests en amont.

Il existe aujourd’hui des outils complets qui permettent de capturer, référencer, analyser ce type d’indicateurs, et d’alerter en cas de régressions par rapport aux seuils préalablement définis. Ce qui permet, par exemple, d’identifier une anomalie d’architecture quelques minutes seulement après que le développeur a écrit le code ou changé la configuration d’une fonctionnalité.

Anticiper ainsi les problèmes de performance dès la phase de développement, permet d’éviter les goulots d’étranglement qui surgissent dans le pipeline lorsque des changements de code non optimisés s’y accumulent. En stoppant les « mauvais builds » plus tôt, les phases de tests peuvent être appréhendées avec davantage de confiance et de sérénité, et les délais de mise en oeuvre entre le commit et la production, considérablement réduits.