Principaux composants du pipeline DevOps

Aujourd’hui, la culture du développement logiciel vise à développer, tester et déployer rapidement des applications. Les outils d’automatisation avancés jouent un rôle essentiel à cet égard. DevOps adopte ces éléments méthodologiques et techniques et les applique à des projets logiciels concrets.

Cet article présente les concepts DevOps, les principaux composants du pipeline DevOps et des conseils pratiques pour intégrer la méthodologie DevOps au cycle de vie du développement logiciel (SDLC).

Qu’est-ce qu’un pipeline DevOps ?

Un pipeline DevOps aide les équipes à créer, tester et déployer des logiciels rapidement et efficacement grâce à une combinaison d’outils et de pratiques. Il facilite également la maintenance et les mises à jour des logiciels. De plus, un pipeline DevOps simplifie l’intégration continue des modifications de code dans un dépôt amont, automatise les tests et les builds, et permet de résoudre efficacement les conflits de code et de détecter les bugs et les vulnérabilités. Les pratiques DevOps réduisent ainsi le délai de mise sur le marché (TTM) et favorisent des processus de développement logiciel agiles.

Intégration continue (CI)

L’intégration continue (CI) consiste à fusionner régulièrement le code des développeurs dans un dépôt de code partagé, puis à appliquer à ce code des tests unitaires, des builds et des outils de vérification automatiques. La CI a pour principaux objectifs de rendre la vérification du code efficace et d’éviter les conflits de code au moment de la livraison.

Pour ce faire, le code envoyé vers le dépôt partagé est automatiquement compilé en un artefact et testé. Lors de ce processus, appelé build, tout échec entraîne l’envoi d’une notification aux développeurs concernant les tests et assertions en échec, afin qu’ils puissent corriger le code. Le pipeline CI est généralement associé à des pratiques standard de gestion du code, comme les pull requests.

La CI évite les problèmes d’« enfer de l’intégration » et de « jour de fusion » lorsque différentes branches du code doivent être rapprochées.

Livraison continue (CD)

La livraison continue (CD) consiste à empaqueter le code en unités livrables pouvant être déployées en production. Il ne faut pas confondre la CD avec le « déploiement continu », qui désigne le déploiement automatique des modifications de code en production.

L’environnement CD comprend un environnement de test proche de la production, où les mises à jour incrémentielles du code sont testées et publiées. Après la revue du code et les tests, les développeurs peuvent envoyer les modifications en production. La mise en production de petites mises à jour du code facilite le dépannage et contribue à éviter les goulots d’étranglement logiciels et les conflits de fusion. Les tests préalables dans l’environnement de test rendent généralement plus stables les applications déployées en production via la CD et réduisent le nombre de bugs.

Déploiement continu (CD)

Le déploiement continu (CD) désigne la publication automatisée des mises à jour de code à destination des utilisateurs, sans vérifications ni déclencheurs manuels. Comme pour la livraison continue, des builds et des tests automatisés sont appliqués au code, mais les modifications sont immédiatement déployées en production. La CD permet donc de publier les produits le plus rapidement possible. Elle présente toutefois des limites. Par exemple, des bugs et des vulnérabilités non détectés par les vérifications automatisées peuvent être déployés en production. Elle doit donc être appliquée avec précaution et réservée aux modifications mineures du code. Il convient également de l’associer à des stratégies efficaces de mises à jour progressives (par exemple, les déploiements blue/green et les déploiements canary).

Créer un pipeline DevOps

Un pipeline DevOps efficace doit comprendre les composants de base suivants :

• Framework CI/CD

• Gestion du contrôle de version

• Outils d’automatisation des builds

• Framework de test du code

Il peut également inclure des outils de pipeline pour la sécurité des conteneurs et la sécurité IaC. De nombreux outils DevOps open source peuvent vous aider à créer un pipeline DevOps efficace.

Framework CI/CD

Les frameworks CI/CD tels que Jenkins ou Travis CI facilitent la mise en œuvre du composant CI/CD du pipeline DevOps. Ces frameworks comprennent généralement un serveur capable d’effectuer automatiquement des builds, des tests et des déploiements logiciels à partir des commits de code reçus. Votre outil CI/CD doit donc être connecté au dépôt de code source.

Gestion du contrôle de version

Les outils de gestion du contrôle de version (ou de gestion des versions) permettent de suivre et de gérer les modifications de code. Ils conservent un historique continu du développement du code, notamment les commits individuels des développeurs et les pull requests. Ils facilitent également l’envoi des modifications de code vers des dépôts distants et la résolution des conflits entre les différentes contributions. Parmi les outils de gestion du contrôle de version, Git possède l’écosystème le plus développé et est le plus populaire.

Outils d’automatisation des builds

Les outils d’automatisation des builds permettent de transformer le code d’une application en un objet déployable. Leurs fonctionnalités varient selon le type de langage de programmation utilisé : compilé ou interprété.

Les outils destinés aux langages compilés comme C++ ou Java ne se contentent pas de compiler le code : ils génèrent un environnement de build natif permettant de compiler le code source, de créer des bibliothèques, de générer des wrappers et de créer des exécutables dans différentes combinaisons. Les outils de build pour les langages interprétés comme Grunt, Webpack, Rollup et Babelpour JavaScript peuvent servir à concaténer des fichiers JavaScript, mais aussi à les obfusquer et à les réduire.

Framework de test du code

Les frameworks de test du code aident les développeurs à détecter les erreurs dans les applications pendant le développement. Ces outils comprennent généralement des fonctionnalités de tests unitaires qui peuvent être intégrées au code de l’application et exécutées au moment de son exécution. Autre avantage : les frameworks de test du code peuvent être intégrés aux outils CI/CD existants pour automatiser le processus. Il existe de nombreux frameworks de test pour les différents langages de programmation (par exemple, Pytest pour Python et JUnit pour Java).

Il est également possible d’intégrer des analyses de la qualité du code et des vulnérabilités au processus de build en ajoutant un test automatisé de Snyk Code à votre CI/CD.

Exemple de pipeline Azure DevOps

La plupart des fournisseurs cloud proposent divers outils pour créer dans le cloud un pipeline DevOps de niveau production. Pour illustrer à quoi ressemble un pipeline DevOps cloud en conditions réelles, examinons le pipeline Microsoft Azure DevOps, qui se compose de différents éléments, notamment :

• Azure Pipelines

• Azure Test Plans

• Azure Repos

• Azure DevOps Server

Ces outils fournissent tous les éléments de base DevOps décrits ci-dessus.

Voici à quoi pourrait ressembler le processus d’utilisation du pipeline Microsoft Azure DevOps :

1. Le code d’une application est mis à jour.

2. Les modifications de code sont enregistrées dans le dépôt de code Azure Repos.

3. Un événement CI déclenche le build de l’application et les tests unitaires avec Azure Test Plans.

4. Azure Pipelines automatise le déploiement des artefacts de l’application.

5. Les artefacts sont déployés sur Azure App Service.

6. Une fois l’application déployée, les spécialistes DevOps peuvent surveiller son état, ses performances et d’autres indicateurs.

Intégrer la sécurité au pipeline DevOps

La sécurité des applications fondée sur les approches de sécurité traditionnelles, encore utilisées par de nombreuses organisations, n’est pas compatible avec DevOps. Ces approches présentent généralement plusieurs limites :

• La sécurité est généralement prise en compte après la mise en production du logiciel, plutôt que d’être intégrée dès sa conception.

• Le cycle de retour d’information lent des pratiques de sécurité traditionnelles est incompatible avec le rythme soutenu d’un pipeline DevOps.

• Les méthodologies de sécurité traditionnelles ne tiennent pas compte des environnements changeants dans lesquels évoluent les applications modernes (par exemple, les services cloud, les conteneurs et les systèmes de gestion des conteneurs comme Kubernetes).

Les équipes de sécurité qui suivent l’approche traditionnelle restent à l’écart des équipes DevOps. Elles relèvent généralement d’un autre responsable et travaillent en silos. Résultat : des applications non sécurisées sont livrées, car les experts ne participent pas aux échanges et ne disposent pas des informations dont ils ont besoin.

De plus, dans ces situations, lorsque les équipes de sécurité interviennent pour effectuer un audit, elles ralentissent la livraison et font ainsi échouer l’objectif commercial initial. Pour ne rien arranger, les équipes de sécurité manquent souvent cruellement de personnel, une situation aggravée par la grave pénurie de talents qui touche le secteur de la cybersécurité.

Lorsque les équipes de sécurité détectent des vulnérabilités et d’autres risques, elles ne sont pas en mesure de corriger elles-mêmes les problèmes. La recherche d’une solution est confiée à l’équipe de développement et, tant que les problèmes ne sont pas priorisés et traités, le risque persiste. Cela crée un nouveau goulot d’étranglement pour les corrections de sécurité.

Ces limites des approches de sécurité traditionnelles compliquent l’intégration de la sécurité dans un environnement DevOps moderne fondé sur l’automatisation et les outils CI/CD. La sécurité reste extérieure au processus de développement logiciel et intervient à titre correctif, une fois le produit créé. Heureusement, il existe une solution à ce problème.

La sécurité pensée pour les développeurs et DevSecOps

Dans ce monde transformé par le numérique, le cloud et DevOps, il est évident qu’une nouvelle approche de la sécurité s’impose. Cette approche, parfois appelée DevSecOps, doit s’appuyer sur ces nouvelles technologies et méthodologies et intégrer la sécurité au cœur de leur fonctionnement. Elle doit favoriser l’autonomie des équipes et accélérer l’activité plutôt que la ralentir. En d’autres termes, elle doit donner la priorité aux développeurs.

Qu’est-ce que DevSecOps ?

DevSecOps consiste à intégrer les pratiques de sécurité à un modèle de livraison logicielle DevOps. Cette approche prolonge naturellement DevOps en ajoutant une dimension sécurité au principe de « responsabilité partagée ». DevSecOps considère la sécurité comme une fonctionnalité intégrée au logiciel, soumise aux mêmes processus de vérification et de conformité que les autres composants du pipeline DevOps.

Voici quelques-uns des principaux avantages de DevSecOps :

• Intégrer les activités et les outils de sécurité dès les premières étapes du cycle de vie du développement logiciel.

• Accélérer la livraison des logiciels grâce à la détection précoce des bugs et des vulnérabilités, corrigés avant le déploiement, afin que les développeurs puissent se concentrer sur la livraison de fonctionnalités utiles.

• Les outils d’automatisation de la sécurité permettent aux développeurs qui ne sont pas spécialistes de la sécurité de créer des logiciels stables et sécurisés.

Il existe quelques exemples de réussite de la mise en œuvre d’une approche DevSecOps et de l’intégration de la sécurité aux pipelines DevOps. Chez Coveo, les membres de l’équipe DevOps peuvent gérer les vulnérabilités avec beaucoup plus d’autonomie et d’efficacité. Le Security Champion de chaque équipe est habilité à surveiller les vulnérabilités et à décider lui-même de la manière et du délai pour les traiter. Les équipes DevOps de Coveo bénéficient d’un accompagnement, mais ont globalement la responsabilité et le pouvoir de prioriser leurs actions en matière de sécurité. Le soutien de Snyk à cette approche « faire confiance, mais vérifier » a largement facilité son adoption dans toute l’organisation.

Le pipeline de déploiement a d’abord été créé par une petite équipe, puis mis à la disposition de tous les développeurs », a expliqué Beaumont. « Nous n’avons pas vraiment eu besoin de convaincre les équipes de développement d’adopter le nouveau pipeline, compte tenu de tous ses avantages en matière de sécurité et de facilité d’utilisation. La transition s’est faite naturellement. »

Jean-Philippe Lachance, analyste en sécurité, Coveo

Conclusion

Dans cet article, nous avons découvert les principaux composants du pipeline DevOps et comment l’intégrer au processus de développement logiciel. Se lancer dans DevOps ne consiste pas seulement à choisir les bons outils : il faut aussi mettre en place des pratiques et une culture organisationnelles DevOps solides, fondées sur la responsabilité partagée, l’automatisation et la collaboration entre développeurs, administrateurs et spécialistes des opérations.

Mais n’oubliez pas que le pipeline DevOps ne vise pas uniquement à accélérer le développement et les mises en production : il s’agit aussi de garantir la sécurité de vos applications. Pour cela, il faut intégrer la sécurité à votre pipeline DevOps et fédérer les différentes équipes autour de l’objectif de concevoir des applications sécurisées dès le départ. C’est pourquoi les pratiques émergentes du DevSecOps abordées dans cet article gagnent du terrain dans le mouvement DevOps actuel.

FAQ sur DevOps