Comme vu dans notre précédent article "Les grands principes de la démarche DevOps", l'un des piliers du devops repose sur la capacité à itérer rapidement.
Mais cette vélocité doit être présente à tous les étages de la création de logiciel. Si votre équipe est capable dans la durée de produire régulièrement des fonctionnalités sans affaiblir la qualité technique du produit, vous êtes déjà à un stade avancé.
Mais si ce code reste bloqué sur les machines de vos équipes, vous conviendrez que cela n'a pas grand intérêt.
Il n'est pas rare de tomber sur des équipes de développement qui sont bien organisées, capable de produire des fonctionnalités régulièrement, mais qui se retrouvent bloquées par un goulot d'étranglement : l'incapacité à envoyer simplement les développements dans un environnement de recette, et à ce que le métier puisse les valider en conséquence.
Dans cette situation, on rentre généralement dans une spirale négative : plus les équipes ont de fonctionnalités ouvertes, plus il leur devient complexe et lent d'avancer.
En effet, deux possibilités sont offertes aux développeurs : soit ils vont démarrer la nouvelle fonctionnalité (B) sur base de l'application actuellement en production, soit sur les bases de la fonctionnalité A, qui n'a pas encore été validée.
On le comprend aisément, aucune des deux situations n'est idéale. Dans le premier cas (à gauche sur le schéma), si la fonctionnalité A n'est pas validée par le métier, il faudra la modifier et en conséquence ré-intégrer ces changements dans la fonctionnalité B.
Dans le second cas (à droite sur l'image), on s'expose à des effets de bord. Les deux fonctionnalités peuvent être validées en isolation, et pourtant ne pas fonctionner ensemble. Sans compter que leur intégration peut entraîner des conflits, notamment si ces deux fonctionnalités touchent à des même parties du code.
Ajoutons à cela que la complexité s'accroît de façon exponentielle si on augmente le nombre de fonctionnalités développées en parallèle. Si on démarre une fonctionnalité C, on a maintenant la possibilité de la démarrer depuis 3 états différents : celui de la production, de la fonctionnalité A ou de la fonctionnalité B.
Ce problème n'a pas de solution idéale, et la meilleure réponse à donner est donc d'éviter son apparition. Pour cela, il faut être en mesure de pouvoir déployer rapidement les fonctionnalités développées. Et plus l'équipe est étoffée, plus le processus doit être solide et démultipliable.
Les pré-requis d'un bon environnement de recette
À priori, tout le monde est d'accord pour dire que la validation doit se faire dans un environnement de recette. Mais s'il peut paraître simple et évident de définir ce qu'est un bon environnement de recette, il y a pourtant beaucoup de questions à se poser :
- De combien d'environnements de recette ai-je besoin ?
- De combien d'environnements je peux disposer, par exemple en terme de budget ?
- Ai-je la possibilité de mettre mon environnement de recette dans un état consistant, notamment en terme de données ? Est-ce que ce jeu de données représente une situation fidèle à la réalité ?
- Ai-je le droit de ré-injecter des données de mon environnement de production dans un environnement de recette ? (👋RGPD)
- Les données de mon environnement de recette sont-elles anonymisées ? Détruites après usage ?
- Est-ce que je peux / veux être ISO production ?
- Est-ce que j'ai un processus pour provisionner un environnement complet ou est-ce que je maintiens un environnement donné ?
- Ces environnements sont-ils limités en terme d'accès et s'inscrivent-ils dans ma politique de sécurité du système d'information (PSSI) ?
- Est-ce que j'utilise des mots de passe faibles sur ces environnements pour faciliter la recette ?
- Combien de temps suis-je prêt à attendre entre l'envoi du code et la possibilité de tester sur un environnement donné ?
- Est-ce que je dois jouer des tâches sur mon environnement lorsque j'y déploie mon application ? (par exemple des migrations).
Spontanément, on peut se dire que le mieux est d'être ISO production. Mais si votre système d'informations contient cinquante microservices, pas sûr que cela soit intéressant, ni économique. Et si vous avez besoin de quatre environnements ISO production, on imagine également l'impact que cela peut avoir sur les coûts.
De plus, si ces environnements sont déployés et maintenus à la main, c'est une charge de travail colossale.
Il n'y a donc pas de réponse parfaite à ces questions. Le plus efficace est de partir des enjeux et des moyens pour trouver la meilleure solution : celle adaptée à vos besoins.
Pour certains de nos clients, nous mettons en place du provisioning d'environnement qui leur permet de répliquer l'ensemble de leur système d'informations pour tester une fonctionnalité donnée, avec la possibilité de supprimer l'environnement créé derrière.
Comme on est sur de la consommation à la ressource, les coûts sont acceptables même si le système d'information est assez complexe. La contrepartie est que, même si c'est automatique, cela prend du temps pour avoir cet environnement à disposition.
Cela signifie que le développeur doit être assez sûr de son développement avant de lancer cette action de provisioning d'environnement, car il ne peut pas se permettre de la lancer toutes les 5 minutes.
Pour d'autres clients, nous avons mis en place des environnements de feature permanents. L'avantage est qu'ils sont simples à utiliser et il est rapide pour les développeurs d'y envoyer leurs modifications. Par contre, ces environnements ne sont pas parfaitement identiques à la production.
Bien outiller les développeurs pour fluidifier les déploiements
Une fois que vous avez choisi comment gérer vos environnements (et ce choix peut et doit évoluer dans le temps), il est impératif d'outiller vos équipes de développement en conséquence.
Idéalement, il est de bon ton de mettre en place un système de packaging des applications qui permettra de faire tourner les applications de la même façon, aussi bien en développement qu'en environnement de recette et de production. Les variations se faisant principalement par le biais de la configuration.
Cela peut se faire au travers de la conteneurisation ou de la virtualisation. Quel que soit le moyen utilisé, le but est que l'intégration ou le retrait d'une dépendance par le développeur localement puisse automatiquement être acheminé jusqu'à la production, sans effort supplémentaire.
Une fois en place, il faut que le développeur puisse envoyer simplement ses modifications sur un environnement donné.
On voit sur cet exemple d'intégration continue de l'un de nos clients, qu'il dispose d'une action manuelle permettant d'envoyer l'application vers l'un des 4 environnements de pré-production. Dans ce cas, les environnements ne sont pas créés à la volée, le déploiement de l'image applicative est donc très rapide.
Et comme c'est simple à utiliser, les développeurs l'utilisent volontiers, le recettage en est accéléré, et l'atterrissage en production également.
Lorsque l'on parle de livraison continue, il est donc important de se poser en amont les bonnes questions, relatives aux enjeux.
Lorsque ces questions ont fini d'être posées, et qu'on connaît ses objectifs, le but du jeu va être avant tout d'éviter les embûches et de retirer tous les obstacles qui peuvent se dresser entre l'équipe de développement et la mise en production. C'est un processus qui se raffine au fil du temps et qui permet de garder une bonne vélocité dans ses équipes.
