Expertise DevOps
Au delà du terme à la mode, il y a derrière l’expression “DevOps” plus l’idée de réaligner les objectifs des équipes de Développement et d’Opération que l’intitulé d’une fiche de poste. Le DevOps est une méthode agile dont l’objectif et l’amélioration continue d’un produit pour l’utilisateur final.
Notre approche.
Avec le DevOps, augmentez la fréquence de vos release et diminuez les erreurs en production
avec une automatisation accrue et des cycles plus courts.
Pour cela le DevOps préconisera notamment le développement par itération afin de produire des fonctionnalités qui ont du sens pour l’utilisateur ainsi que toute une chaîne d’automatisation de test et de déploiements pour allier consistances des opérations et rapidité d’exécution.
L’objectif de l’expertise DevOps d’Invivoo est de partager une veille technique, les bonnes pratiques et les synergies possibles entre les outils DevOps. Faire travailler deux métiers historiquement séparés est le moteur de cette philosophie et notre objectif.
Arthur Ortin
Manager de l'expertise DevOps
Actualités.
Tu es passionné ?Nous aussi !
Alors rejoins-nous.
Nos autres expertises Deliver & Run
Pourquoi passer par un cabinet de conseil en DevOps?
Qu’est-ce que le DevOps ?
Le terme « DevOps » est la contraction de deux organes importants dans le monde de l’IT :
- Le développement (« Dev ») en charge de concevoir et produire le code des logiciels
- Les opérations (« Ops ») en charge de la gestion des environnements, des infrastructures et du déploiement des artefacts produit par le développement
DevOps a pour objectif premier de réduire les frictions entre les équipes qui composent ces deux organes en les désilotant et en introduisant des profils Ops dans des équipes de développement ou inversement afin de lier étroitement ces deux cultures. En effet, le silotage historique de ces deux parties de l’IT a fait naître de nombreuses frictions entre elles car elles n’ont pas nécessairement les mêmes objectifs : l’ajout de changements permanent du côté du développement pour s’adapter aux nouveaux besoins des utilisateurs et un conservatisme du côté des opérations pour assurer la plus grande stabilité des environnements et des applicatifs.
Au même titre que l’agilité, le DevOps est avant tout une façon de travailler, une méthodologie. Le DevOps est d’ailleurs très proche de la mouvance agile. Ses objectifs se retrouvent dans plusieurs principes sous-jacents à l’agilité :
- « Livrer fréquemment un logiciel opérationnel »
- « Un logiciel opérationnel est la principale mesure d’avancement »
- « A intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace »
Bien sûr, comme pour l’agilité, le DevOps vient aussi avec des pratiques (Intégration continue, Livraison continue, Déploiement continu …) et des outils (des orchestrateurs comme Jenkins, Ansible, le Cloud, Terraform pour l’Infrastructure As Code …).
En plus de son objectif initial, le Devops a aussi pour but de :
- Garantir une meilleure qualité du produit par l’automatisation des tests entre autres
- Réduire le time to market grâce à l’automatisation de nombreux processus
- Accélérer les feedbacks pour les développeurs et les Ops
- Standardiser les processus de développement, de déploiement et de monitoring
- Maîtriser et contrôler les mises en production par cette standardisation
- Simplifier la reprise sur panne
Le DevOps est bien au service du développement et des opérations et fait en sorte que ces deux parties fonctionnent bien main dans la main pour atteindre le même objectif : une livraison continue de valeur au métier en maintenant la qualité et la stabilité.
Qu’est-ce que le DevOps n’est pas ?
La notion de DevOps n’est pas toujours claire pour toutes les organisations.
De nombreuses entreprises considère le DevOps comme une nouvelle fonction dans une équipe : une personne en charge des problématiques de déploiement, de la gestion des environnements et de l’automatisation. Si l’on introduit une seule personne ou un groupe de personnes seules responsables de ces aspects dans une équipe de développement, on ne fait que déplacer le problème initial auquel souhaite répondre le mouvement DevOps. Il y aura toujours un silotage entre les activités de développement et les activités Ops et un manque de diffusion des cultures Dev et Ops de part et d’autre. Il peut toutefois avoir une ou plusieurs personnes avec le titre de DevOps dans une équipe de développement, mais il ne faut pas tomber dans le risque où ces DevOps soient les seuls à gérer les activités Ops. Ils doivent plutôt diffuser la culture DevOps au sein de l’équipe de façon à ce que l’ensemble des membres de l’équipe ait cette culture et l’applique au quotidien.
L’utilisation des technologies Cloud a actuellement le vent en poupe jusqu’au point où certaines organisations confondent DevOps et Cloud. La méthodologie DevOps ne s’applique pas qu’au Cloud et aux services managés qui y sont proposés. Il s’applique tout aussi bien sur une infrastructure on-premise.
Le DevOps n’est pas un monolithe de dogmes à implémenter intégralement pour se considérer comme « DevOps ». Le DevOps peut s’implémenter partiellement en fonction du contexte. Ainsi, il peut se mettre en place graduellement afin d’accompagner les équipes dans leur adoption de cette méthode.
Quelles sont les grandes briques que gère DevOps ?
Le DevOps repose sur les grandes briques suivantes qui représentent ses principaux champs d’action :
- L’Intégration Continue (ou CI pour Continuous Integration) permet de s’assurer que tout nouveau développement est fonctionnel et n’entraîne aucune régression en automatisant le processus de build des artefacts (ce qui inclue généralement la compilation et l’exécution des tests) et l’analyse du code. L’Intégration Continue a aussi pour objectif d’automatiser l’intégration des nouveaux développements dans la base de code existante.
- La Livraison Continue (ou CD pour Continuous Delivery) est la capacité de déployer automatiquement les artefacts produit par l’Intégration Continue sur un ou plusieurs environnements, ces environnements pouvant eux-mêmes être construits automatiquement via des outils d’Infrastructure As Code. Parfois, on peut parler de Déploiement Continu (ou Continuous Deployment) qui est proche de la Livraison Continue à l’exception qu’il prévoit un déploiement en production sans intervention manuelle. La Livraison Continue peut automatiser le déploiement en production, mais celui sera toujours déclenché manuellement.
- L’Opération Continue (ou CO pour Continuous Operation) assure la traçabilité du déroulement, du contenu des livraisons et de manière générale limite au maximum les moments d’inaccessibilité du service
- La Supervision (ou Monitoring) récolte et agrège les messages remontés par l’application, surveille le comportement du système hébergeant l’application et alerte en cas d’anomalie.
Quels sont les différentes étapes du cycle DevOps ?
Le DevOps est souvent représenté sous la forme du sigle infini car il s’agit d’un cycle qui se répète indéfiniment. Ce cycle est composé des étapes suivantes :
- « Plan » : Cette étape consiste à déterminer et construire l’ensemble des besoins auxquels il faut répondre avec la prochaine version du produit
- « Code » : Il s’agit de la phase de développement de ces fonctionnalités
- « Build » : Cette étape permet de construire les artefacts qui seront déployés et qui seront nécessaires pour que la solution soit opérationnelle
- « Test » : Cette phase est l’exécution automatique de l’ensemble des tests développés en amont lors de la phase « Code ». Ces tests peuvent être de différentes natures en fonction des besoins du contexte : tests unitaires, tests d’intégration, tests de performance, tests de bout en bout…
- « Release » : Il s’agit du versionning de la solution qui sera déployé
- « Deploy » : Cette étape consiste à déployer les artefacts produits au préalable sur les environnements concernés par l’étape dans laquelle on se trouve
- « Operate » : Il s’agit du maintien en bonne condition d’utilisation de l’applicatif
- « Monitor » : Cette étape est bien sûr fortement liée à la phase « Operate ». On ne parle pas ici uniquement du monitoring au sens Ops du terme, mais aussi du suivi des retours clients, de l’utilisation de la solution par les utilisateurs qu’il est possible et bon de mesurer… A partir de l’ensemble de ces retours, un nouveau plan est défini pour un prochain tour du cycle.
Les quatre premières étapes concernent plus le monde du développement et les quatre dernières le monde des opérations, mais sont étroitement liées car elles ont des impacts l’une sur l’autre.