Par Marc Chaigneau*, dont le dernier essai « De la révolution à l'inversion** », se consacre à une réforme de notre société.
1/ De quoi parle-t-on ?
« Intégration continue” (CI), “Déploiement continu” (CD), “Devops”, autant de termes que l’on entend fréquemment dès que l’on parle d’application Web et de transformation numérique, et pourtant ce sont des concepts encore mal connus dans leur mise en œuvre.
De quoi s’agit-il ? Tout simplement d’assurer la sortie sur un rythme beaucoup plus régulier et rapide des nouvelles fonctionnalités d’une application.
Traditionnellement, un rythme de déploiement standard sur une application classique est d’une à deux versions majeures par an: pour chacune, on regroupe un ensemble de nouvelles fonctionnalités. Cela donne un délai de 6 à 12 mois entre deux nouveautés, entre temps on se contente de corriger les bugs et livrer des versions mineures. C’est terriblement long, surtout à l’ère d’internet. L’objectif est d’assurer la cohérence de l’ensemble, de regrouper les tests, de sécuriser la production et de limiter les migrations pour les clients.
Ce délai s’explique aussi par le fait que c’est un processus séquentiel qui implique différentes équipes et qu’à chaque étape, il faut synchroniser les acteurs, faire des demandes, les planifier, tout cela générant des délais.
Le déploiement continu prend le contrepied et vise à accélérer ce rythme en :
- découpant les versions en un plus grand nombre de livraisons de moindre taille et moins complexes à tester,
- automatisant au maximum les étapes de tests et passages en production d’une nouvelle version afin de réduire les cycles,
- permettant un déploiement très régulier des nouveautés.
2/ Quel est l’enjeu ?
Les applications traditionnelles étaient pour l’essentiel des applications de back office auxquelles les clients et partenaires n’accédaient pas, ou indirectement.
Les applications web sont au contraire en frontal avec les clients ou partenaires qui vont s’y connecter directement pour traiter leurs opérations. L’objectif est que la navigation de l’internaute soit intuitive et les transactions simples et fluides. On parle d’optimisation du parcours utilisateur, d’”UX” (Interface utilisateur), d’apporter la “meilleure expérience”. Bref une véritable course contre la concurrence pour rendre les applications les plus performantes à utiliser et améliorer le “time to market”.
Dans ces conditions, on comprend qu’attendre 6 mois pour sortir une modification n’est pas envisageable. C’est là que le Devops prend tout son sens et apporte une réactivité supérieure (on parlera d’agilité). On va chercher à livrer en production rapidement, au fil de l’eau, les développements réalisés et testés pour en faire bénéficier au plus vite les clients.
Dans un contexte de numérisation de l’économie et des échanges, c’est bien d’un enjeu de compétitivité d’entreprise dont on parle. A cela s’ajoute les contraintes spécifiques des technologies web qui évoluent très vite : les designs se périment en 2 ou 3 ans, une technologie est remplacée en 4 ans...Tout concourt à accélérer le rythme de renouvellement et d’évolution des applications web.
3/ Comment y aller ?
Maintenant que nous sommes convaincus de la nécessité d’accélérer la cadence, comment fait-on pour y aller, que faut-il mettre en œuvre ?
Devops
Le principe de la méthode Devops est de rapprocher les équipes de développement (Dev) des équipes d’infrastructures et de production (Ops) en intégrant dès la conception du projet toute la chaîne: la conception de l’architecture logicielle et les développements, les tests, comme les contraintes d’infrastructures et les méthodes de production. On vise ainsi avec Devops à réduire les incohérences et ruptures de charges entre les développeurs et les équipes d’infrastructures.
Les “two pizzas team”
Le terme de “two pizzas team” a un côté gadget mais il faut en retenir l’idée qui est de confier à une équipe réduite (2 pizzas format US = une douzaine) un ensemble cohérent de fonctionnalités sur un périmètre limité. L’équipe est de taille assez réduite pour se piloter simplement, elle connaît son domaine fonctionnel à fond, et elle est responsable de l’ensemble depuis la conception jusqu’à la mise en production en passant par les tests.
Au-delà de son côté caricatural, tout n’est pas manageable en “two pizza team”, mais on voit bien que cela rejoint bien l’idée du Devops : regrouper les responsabilités et réduire les pertes de temps entre deux équipes
La chaîne de mise en production
Accessible via le lien ci-dessous, retrouver le schéma qui illustre les étapes de déploiement d’une nouvelle fonctionnalité dans un schéma traditionnel, chacune est gérée par une équipe distincte à qui il faut faire une demande, qui doit être planifiée, et cet enchaînement prend du temps à chaque transition.
http://www.docaufutur.fr/2016/12/21/integration-deploiement-continus-capital-y-aller-christophe-lejeune-directeur-general-dalfa-safety/
4/ L’intégration continue
L’intégration continue couvre la première moitié de la chaîne. Elle vise à organiser au mieux et automatiser les opérations et leurs transitions :
- Un serveur de gestion des versions logicielles (SCM) permet aux développeurs de travailler sur leur poste tout en centralisant la gestion des versions ; dès qu’un nouveau code est jugé prêt, il est “poussé” vers le serveur d’intégration. Les outils SCM les plus répandus sont actuellement Git (et Github) et Subversion (SVN),
- Un serveur d’intégration (CI) vient récupérer le code et réaliser les tests et, si le résultat est au vert, l’intégrer une nouvelle branche du code qui sera poussée à la fois sur le serveur SCM et vers la recette. Les outils phares sont ici Jenkins, CircleCI, CodeShip ou encore TravisCI.
- Les développeurs peuvent ainsi se concentrer sur leurs actions de conception/développement ; ils disposent d’un serveur pour gérer leurs sources tout en travaillant de manière décentralisée, et dès qu’un lot de code est prêt, il est traité par le serveur de CI en réduisant les tâches manuelles au minimum.
5/ Le déploiement continu
Le déploiement continu prend la suite : il consiste pour l’équipe infrastructures à automatiser les étapes de déploiement en production afin qu’une version livrée par le serveur CI puisse être déployée rapidement en production.
- Un serveur de configuration d’infrastructures centralise les modèles de configuration des serveurs (production et recette), qui serviront pour provisionner tout nouveau serveur. Les outils utilisés : Chef, Puppet, SaltStack ou encore Ansible.
- Une automatisation maximale des tests de recette, via un outil comme Selenium, qui permet d’enregistrer et dérouler des scénarios complets de test.
- Un serveur de déploiement va orchestrer les opérations de déploiement sur le serveur de recette, déclencher les tests, puis lancer le passage en production si ces derniers sont positifs, Parmi les outils d’orchestration fréquemment utilisés pour les applications web, on peut citer Capistrano.
- Tout ne sera pas automatisé à 100% et il est bon de conserver des validations manuelles, mais l’idée est bien de supprimer toute les ruptures de charge non indispensables.
- Le déploiement en production bien organisé sur une application web peut ainsi se faire sans coupure de production ou en horaire décalé sans présence humaine.
On voit que le rôle de l’équipe d’infrastructures change, il n’est plus de réaliser les opérations de déploiement, mais de créer des modèles de configurations ainsi que des chaînes d’automatisation, de les mettre à jour, et de les superviser.
6/ Un changement de culture et une démarche graduelle
Au-delà des outils et des méthodes, l’organisation devra être adaptée, les intervenants formés ; c’est une évolution de culture professionnelle, il y a donc une gestion du changement à mener. Le métier de l’administrateur d’infrastructures s’en trouve transformé, de même que celui du développeur, ainsi que les relations entre ces deux équipes. La nouvelle chaîne de déploiement permet aux développeurs d’être plus autonomes et de disposer facilement des environnements dont ils ont besoin, ils sont aussi plus responsabilisés. On parle du “retour du développeur” pour qualifier cette évolution.
Enfin Il faut prendre en compte l’investissement en temps/homme pour les équipes. C’est pourquoi, s’il faut avoir un plan macro, une démarche graduelle est le plus sûr moyen d’engranger rapidement des premiers gains et d’arriver plus vite à l’objectif complet.
7/ L’impératif du “time to market” en maîtrisant les coûts
L’objectif de cette organisation est de faire en sorte que le nombre de versions et l’étape de mises en production ne soient plus des contraintes. L’entreprise gagne ainsi en agilité et en “time to market” pour déployer de nouvelles fonctionnalités, toutes les semaines, tous les jours même s’il le faut, et sur des cycles courts, 15 jours, 1 mois, selon l’ampleur du développement à réaliser. Mais l’entreprise gagne aussi, et ce n’est pas négligeable, en efficacité et en coûts, parvenant à produire plus avec la même équipe informatique.
C’est tout le marché du développement web qui a commencé à basculer dans cette voie, les jeunes entreprises du web sont montées dans le train les premières, pour celles dont la culture est moins internet, la transition impliquera davantage de changements, raison de plus pour s’engager sans tarder
* Marc Albert Chaigneau a été conseil de sociétés et avocat d'affaires, puis responsable juridique pendant 35 ans. Cette expérience l'a conduit à analyser méticuleusement la société dans laquelle nous vivons.
** « De la révolution à l'inversion », publié aux éditions Edilivre, propose un nouveau projet
de réforme de lasociété.Un modèle préférable à la révolution en ce qu'il ne nécessite ni violence, ni destruction, mais seulement l'inversion d'un certain nombre de nos comportements.
https://www.alfa-safety.fr/
Lectures du moment, tribunes d'experts, management et entrepreneuriat...
Comprendre l'économie durable pour s'y investir