DevOps : le B.A BA

Si vous n'avez jamais entendu parler de DevOps, vous imaginez peut-être un concept abscons, impénétrable et peut-être même essentiellement marketing. Ou encore un raccourci vers un monde nouveau plein de promesses. Ou peut-être quelque chose entre les deux.

Dans tous les cas, ne vous inquiétez pas : vous en saurez bientôt beaucoup plus sur cette nouvelle approche qui change le monde du développement logiciel.

Dans le passé, la fabrication de logiciels était relativement simple. Une fois le cahier des charges défini avec le client, l'on pouvait passer au développement à proprement parler, puis aux tests de qualité et d'assurance (Q&A).

Une fois que tout semblait fonctionner correctement «?sur les machines des développeurs?» (selon l'excuse consacrée), l'équipe des opérations (Ops) pouvait alors récupérer le code pour tout déployer sur les systèmes dont ils avaient la charge. et voir si cela fonctionnait ici aussi.

Mais il est de plus en plus difficile de continuer à travailler ainsi de nos jours. La pression s'accroît pour que les entreprises déploient de nouvelles fonctionnalités et de nouveaux services au fur et à mesure de leurs besoins, et cela souvent très rapidement.

Or, l'ancien modèle - avec le risque de nombreux allers-retours entre opérations et développement - ne tient justement la route que si la vitesse et l'efficacité ne sont pas des critères importants. Et puisque cela est hélas de moins en moins le cas, cette approche traditionnelle devient donc progressivement incompatible avec les ambitions modernes.

Imaginez par exemple une situation où plusieurs équipes de développeurs travaillent en parallèle sur le même projet. Ce qui arrive d'ailleurs tout le temps. Une fois que tout est codé - voire une fois l'application entière finalisée - il n'est pas rare qu'ils découvrent que certains composants qu'ils ont choisis de manière individuelle sont incompatibles entre eux, et qu'il faille recommencer des portions entières de l'application.

Avec une telle approche, la perte de temps est colossale si toutes les équipes attendent de terminer leurs tâches avant de fusionner le code en une seule application, pour voir ce que ça donne. Le dynamisme du développement s'évanouit et peut devenir un exercice tortueux de nettoyage ou de réaménagement.

Imaginons maintenant un deuxième scénario où l'équipe des tests (Q&A) demande à l'équipe des opérations de tester son application dans un environnement spécifique qui répliquera exactement celui de la production. Sans automatisation, cela peut prendre des jours à l'équipe Ops pour fournir l'environnement requis.

Dans les grandes organisations, de tels retards peuvent même prendre des semaines et peuvent impliquer plus d'un service. Par exemple, les opérations peuvent devoir déployer un nouvel environnement qui nécessite une permission spéciale de l'équipe de sécurité, qui devra alors valider la nouvelle infrastructure au préalable.

Mais pendant ce temps, les développeurs vont probablement continuer à coder de leur côté. Si toutefois un bogue est trouvé pendant les tests, peut-être que les développeurs auront entre temps bâti de nouvelles fonctionnalités entières sur ce défaut, et cela pourrait alors nécessiter une révision majeure du programme.

Alors, comment pouvons-nous empêcher ces frustrations de se produire et garder la livraison du code sur la bonne voie ?

L'approche DevOps a justement été conçue pour s'affranchir des limites précédentes, et voici comment :

- Intégration continue. L'approche DevOps utilise une méthodologie agile où, typiquement, de petits morceaux de code fonctionnels (par exemple, une nouvelle fonctionnalité) sont intégrés régulièrement et de manière transparente dans la branche de développement principale de l'application. Les erreurs sont ainsi repérées et corrigées rapidement. C'est ce qu'on appelle l'intégration continue (IC).

Pour que cela fonctionne, les petits morceaux de code en question sont créés dans leur propre environnement isolé («?conteneurisé?») où chaque composant a généralement un point de communication unique pour «?parler?» aux autres.

Ces points de communication sont connus sous le nom d'interfaces de programmation d'application (API). Cela donne au développeur suffisamment de flexibilité pour ajouter ou supprimer des composants sans affecter le travail des autres. C'est ce qu'on appelle une architecture de microservices, dans laquelle chaque composant a une capacité dite de «?plug-and-play?» pour se connecter aux autres.

- Livraison continue. Après la phase d'intégration continue, le code intégré est testé automatiquement via plusieurs environnements, jusqu'à la préproduction où il est prêt à être déployé. Certaines entreprises n'automatisent pas au-delà de ce stade, préfèrent gérer manuellement le déploiement final (la mise en production). L'interaction CI et CD est appelée CI/CD.

- Déploiement continu. Mais l'objectif ultime du DevOps est d'aller plus loin en fournissant une intégration continue suivie d'une livraison et d'un déploiement continus (CI/CD²). En conséquence, les applications sont automatiquement déployées en production une fois la phase de test et de validation automatiques ci-dessus réussie.

- «?Cloud-centricité?». Le modèle DevOps s'épanouit dans le cloud, car il prend en charge nativement les outils du Cloud et s'appuie sur la vitesse et l'adaptabilité de ces derniers pour fournir l'automatisation nécessaire jusqu'à la mise en production.

- L'infrastructure en tant que code. Une infrastructure fortement automatisée est idéale pour que l'équipe de développement puisse déployer automatiquement du code à chaque étape, du test jusqu'à l'environnement de déploiement. Mais cela n'est possible que si les éléments essentiels de l'infrastructure sont définis par logiciel. Autrement connu sous le nom d'Infrastructure as Code (IaaS), c'est un puissant antidote contre les goulots d'étranglement des opérations et du développement.

Un IaaS approprié devrait comprendre des outils de provisioning qui construisent et déploient l'infrastructure par un simple clic de souris ou en remplissant rapidement un formulaire ou via un modèle (les services cloud en sont d'ailleurs eux-mêmes un bon exemple). Il devrait également comprendre des outils de gestion de la configuration (par exemple la possibilité de mettre à niveau 10?000 serveurs avec une seule commande).

- Collaboration. Plus que la plupart des disciplines informatiques, le succès du DevOps repose largement sur une collaboration intensive, étroite et coordonnée entre les clients, les développeurs et les opérations. Les développeurs doivent se concentrer sur le développement. Les opérations doivent se concentrer sur la gestion de l'infrastructure automatisée.

Tous deux doivent se parler pour découvrir de nouvelles façons d'innover et d'améliorer à la fois les processus de livraison et les produits livrables eux-mêmes. Le travail en silo, c'est du passé?!

Fondamentalement, DevOps est une pratique qui permet d'éliminer les sources de déchets dans le processus de livraison des applications. Elle favorise l'efficacité en optimisant les processus, en supprimant les silos, en utilisant des outils d'automatisation, en standardisant les plates-formes et en établissant une forte culture de la collaboration entre des équipes qui, jusqu'à présent, pouvaient ne pas se parler de manière très régulière.

C'est en définitive un moyen puissant de contourner les goulots d'étranglement des méthodes traditionnelles de développement de logiciels et d'infrastructure, et une force d'innovation inépuisable.

Mais la véritable influence du DevOps commence à peine à se faire sentir, et beaucoup d'innovation reste à découvrir en la matière. Restons donc curieux, ouvert d'esprit, faisons collaborer toutes les équipes impliquées dans le cycle de développement et, surtout, ne revenons pas en arrière?!

_{(crédit photo © Ollyy-Shutterstock)}

Arnaud Lemaire, Expert en cybersécurité - F5.