DevOps, CI et CD, de quoi parle-t-on ?
« Intégration continue » (CI), « déploiement continu » (CD), « DevOps », autant de termes que l’on entend très fréquemment dès que l’on parle d’applications 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 de nouvelles fonctionnalités d’une application sur un rythme beaucoup plus régulier et rapide.
Traditionnellement, un rythme de déploiement standard sur une application classique est d’une à deux versions majeures par an. Pour chaque version majeure, on regroupe un ensemble de nouvelles fonctionnalités, ce qui donne délai de 6 à 12 mois entre deux nouveautés. Entretemps, on se contente de corriger les bugs, de sortir des versions mineures. C’est terriblement long, surtout à l’ère d’internet. L’objectif est d’assurer la cohérence des évolutions, regrouper les testss, sécuriser la production et limiter les migrations pour les clients, mais cela pénalise les délais.
Ce délai s’explique par le fait que c’est un processus séquentiel, impliquant 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 permet d’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.
Quel en 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. 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 ». C’est 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’ajoutent 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 est remplacée en 4 ans. Tout concourt à accélérer le rythme de renouvellement et d’évolution des applications web.
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 toute la chaîne dès la conception du projet : 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 elle-même, 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, car tout n’est pas manageable en “two pizza team”, on voit bien que cela rejoint bien l’idée du DevOps à savoir regrouper les responsabilités et réduire les pertes de temps entre deux équipes.
La chaîne de mise en production
Le schéma ci-dessous 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.
Au sein de chaque étape, différentes actions doivent être outillées pour être automatisées et coordonnées afin de fonctionner de manière optimum.
Voyons donc plus en détail l’organisation et le fonctionnement des opérations qui sont représentées dans le schéma ci-dessous en mode Devops, intégration et déploiement continus:
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 de développement et leurs transitions, elle passe par :
- Un serveur de configuration des versions logicielles (SCM) qui va permettre aux développeurs de travailler sur leur poste tout en centralisant au fur et à mesure les modifications effectuées et gérer ainsi toutes les évolutions ; 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 (SVM), idéalement dans un mode collaboratif.
- Un serveur d’intégration (CI) qui vient récupérer le code et va réaliser une série de tests et, si le résultat est au vert, l’intégrer dans 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 TravisCI.
- Ainsi les développeurs peuvent 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 sans nécessité de planification et en réduisant les tâches manuelles au minimum.
Le déploiement continu
Le déploiement continu prend la suite : il consiste pour l’équipe infrastructures à scripter et automatiser les étapes de déploiement en production afin qu’une version livrée par le serveur CI puisse sans attendre se déployer en production. Cela passe par :
- Un serveur de configuration d’infrastructures sur lequel seront stockées les modèles de configuration des serveurs (production et recette), ainsi tout nouveau serveur provisionné l’est bien selon le modèle en cours. Les outils utilisés sont Chef, Puppet, SaltStalk, ou 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 qui 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.
- Bien entendu, 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.
Un changement de culture et une démarche graduelle
Au-delà des outils et des méthodes, l’organisation devra être adaptée et les intervenants formés. C’est une évolution de culture professionnelle dont l’importance implique une gestion du changement. Si le métier de l’administrateur d’infrastructures s’en trouve transformé, celui du développeur l’est également, ainsi que les relations entre ces deux équipes. La nouvelle chaîne de déploiement permet aux développeurs de pousser leurs travaux simplement au fil de l’eau en production. Ils deviennent plus autonomes pour disposer des environnements dont ils ont besoin, et ils sont moins dépendants de délais de déploiement. Ils en sont aussi plus responsabilisés. On parle du “retour du développeur” pour qualifier cette évolution.
Enfin Il faut prendre en compte l’investissement nécessaire 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 bénéfices et d’arriver plus vite à l’objectif complet.
Améliorer le “time to market” en maîtrisant ses coûts
L’objectif de cette organisation DevOps est de faire en sorte que le nombre de versions et l’étape de mise 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.
