Aujourd’hui, il reste trop d’actions manuelles lors du cycle de vie de nos applications. Nous allons essayer dans ce billet d’aller vers la simplicité et l’efficacité pour écrémer tout ce qui crée de la difficulté.
Tout d’abord, il faut choisir des outils :
Un système de gestion de version standard et actuel : GIT
Le meilleur moyen de se faciliter la vie est d’utiliser un outil le plus standard possible. En faisant celà, on a tout le support nécessaire pour nous aider le jour où on a un problème, ou un cas particulier à résoudre. Par chance, nous en avons un sous la main, de surcroît gratuit et opensource, GIT.
Je ne suis en général pas pour dire à tout le monde de passer sur un seul outil, mais celui-ci est vertueux, courant (voire incontournable), riche et facile à mettre en place.
Si vous ne savez pas comment le mettre en place, vous pouvez vous tourner vers github.com ou gitlab.com qui offrent deux solutions hébergées qui ont des services gratuits, idéales pour commencer. Dans un second temps, je vous conseillerai d’installer gitlab chez vous, ou sur votre cloud préféré. Vous trouverez les ressources nécessaire pour ce faire chez gitlab.com ou chez bitnami (qui fournit des images de machines virtuelles prêtes à tourner).
Une organisation simple de vos dépôts de code
Une fois que nous avons le système de gestion de version, il faut savoir l’organiser. Dans la suite, nous continuerons avec Gitlab.
Qui dit mise en production simplifiée, dit d’éliminer toutes les aspérités qui empêcheront notre projet de glisser sur ses rails. Celà peut paraître une montagne sur certains projets, ce qui fait se demander si le jeu en vaut la chandelle, mais c’est un prérequis.
Découpez vos applications en microservices unitaires
Une règle simple : un dépôt, une application. Si votre application contient une partie web et plusieurs binaires, éclatez-les dans des dépôts différents. Si plusieurs applications partagent une partie de leur code, mais sont indépendantes, déplacez le tronc commun dans un nouveau dépôt qui deviendra une librairie. Ou dupliquez-le en attendant de faire du tri.
Si vous n’arrivez pas à le faire sur vos vieux monolithes, simplifiez-les. Découpez-en des parties qui deviendront des microservices à part, et donc de nouvelles applications.
Si encore, celà vous paraît toujours trop utopique, faites-le d’abord, et dès maintenant, pour les nouveaux projets.
La complexité fait exploser les coûts
Même si vous ressentez ce que je vous propose comme une injonction et que vous n’en voyez pas l’intérêt, dites-vous que c’est la complexité à tous les niveaux qui génère le plus de contraintes dans les systèmes d’information. Pendant des décennies, on s’est créé de la dette technique à tous les niveaux. On a mis de la complexité et des interdépendances dans les applications là où il n’en fallait pas.
Le résultat aujourd’hui amène des applications pour lesquelles la maintenance est devenue impossible et les mises en production hasardeuses. On se retrouve avec des bases de codes dont une partie reste obscure et que personne n’ose aller toucher, et des comportements imprévisibles :
C’est cette part inadmissible de perte de contrôle sur les applications qu’on accepte parce qu’on ne peut pas faire mieux.
C’est le fameux : ‘Tant que ça marche, on ne touche pas"
Il y a pourtant une idée de base à suivre : diviser pour mieux règner
Il faut simplifier pour rendre les choses gérables. Il vous faudra du temps pour démêler les pelotes de laine, mais quand elle le seront, vous verrez plus clair et la maintenance s’en retrouvera facilitée d’un facteur 10.
Quelques règles sont à observer :
- Pas de partage de base de données. Si plusieurs modules utilisent une même base, créez une api devant la base et interrogez-là depuis les autres applications.
- Pas d’échanges de fichiers ou de conf via le système de fichier : Celà suppose que vos applications sont sur une même machine et empêche la scalabilité.
- Utilisez des MoM (message-oriented middleware) pour transmettre les messages entre vos applications.
- Autant que faire se peut, passez par des apis et des socket pour les appels entre applications.
Décorrélez les mises en lignes entre les éléments qui n’ont pas de rapport
Vous mettez en production votre release tous les mois mais vous n’avez pas touché à un module depuis 6 mois ? Pourquoi faire son build et son déploiement ? Pourquoi passer les tests dessus si il n’est pas impacté par le reste du code ? (Car bien sûr, comme vous avez démélé les pelotes de laine, vous savez qu’il n’y a pas d’impact)
Vous faites une mise à jour cosmétique sur le front ? Pas besoin de reconstruire et tester le backoffice. Donc pas obligatoirement besoin de le redéployer non plus. Donc les cycles de développement ne sont pas les mêmes. En cas de besoin, vous pouvez synchroniser les mise en production, notamment si le format des données change dans le backend et impacte le front. Mais ce sera une mise en ligne de feature.
La mise en production à l’ancienne qui dure jusqu’à 8 heures (comme j’en ai connu) a eu son heure de gloire il y a longtemps et cet enfer doit être oublié :
En découpant les applications en modules plus petits et plus simples à gérer, en divisant les mises en production par application, et en ne faisant que celles qui sont nécessaires, on réduit mécaniquement le temps passé pour les mises en prod.
On réduit également la complexité de ces mises en production. Tout comme celle des phases de tests. Le cercle vertueux est enclenché et cette simplification des tâches nous donne la possibilité de les automatiser.
Faire de la mise en production un non-événement
Lorsqu’on a éliminé l’essentiel des risques liés à la complexité de notre mise en production, une grande partie des précautions jusque là prise par les équipes deviennent superflues. Les tests couvrent mécaniquement de façon plus importantes les cas de figure rencontrés et on est plus confiants sur l’issue.
Il reste important de maintenir le calendrier des mises en production des différents modules, mais il n’y a plus besoin d’avoir en direct dev, admins systèmes, chefs de projets et des représentants de chaque équipe pour assister au jour J.
En poussant le jugement plus loin, plus besoin de jour J, non plus.
Le déploiement continu, c’est quand la mise en prod peut arriver n’importe quand, que ce soit par feature ou bugfix. Ça permet également d’identifier plus facilement d’où vient le problème en cas de soucis, car on met moins de nouveau code en production à la fois.
maintenant, nous allons nous intéresser au pipeline (CI/CD) en lui-même, mais ça, ce sera dans un autre article.