Qu’est-ce que le DevOps ? Concepts fondamentaux et bonnes pratiques du DevOps

Objectif commun

Afin de faire converger l’ensemble des équipes vers un objectif commun, il convient de définir cet objectif de façon simple et claire, et de faire en sorte qu’il soit communiqué de façon transparente et régulière à l’ensemble des parties prenantes. Dans la mesure du possible, son état d’avancement doit être évalué en temps réel à l’aide d’indicateurs factuels visibles par tous. Il s’agit d’une règle simple mais sa mise en application permettra de résoudre bon nombre de conflits au quotidien.

Responsabilisation

Encourager la collaboration requiert l’établissement d’un climat de confiance entre les équipes. Chaque participant doit porter la responsabilité de ses actions et de leurs conséquences positives ou négatives, et communiquer sur l’avancement de ses tâches en toute transparence. Une fois de plus, les réalisations doivent être évaluées de façon factuelle pour éviter les conflits. Afin d’encourager l’innovation, il est important de capitaliser sur les échecs. Cela signifie qu’il ne faut pas blâmer un participant si l’une de ses actions produit un effet négatif, mais au contraire analyser la situation de façon factuelle et l’utiliser comme une expérience positive dans le but d’améliorer les processus.

Amélioration continue

Le second volet de l’amélioration continue concerne l’observabilité. En effet, mesurer l’impact de chaque action et collecter au plus tôt les retours des utilisateurs est essentiel pour favoriser l’agilité de l’équipe et une prise de décision pragmatique. Supervision, métrologie et collecte de journaux sont autant d’indicateurs objectifs qu’il convient d’agréger au sein d’une vue orientée métier.

L’amélioration continue est l’une des pierres angulaires du DevOps. En effet, il est recommandé d’intervenir sur le système par petites itérations et de capitaliser sur les réussites et les échecs de chaque étape. Pour garantir la reproductibilité des opérations, chacune d’entre elles doit être minutieusement tracée et documentée. Par ailleurs, la rédaction de procédures favorise également le partage de connaissances. En dernier lieu, les opérations peuvent être automatisées à l’aide de scripts.

Source de vérité unique

La multiplication des ressources documentaires nuit à la productivité de l’équipe. Il est préconisé de stocker l’ensemble des informations relatives à une application au plus proche de l’application elle-même. Dépendances, documentation, procédures de build ou de déploiement, tests… Tout ce qui concerne une application doit être rapidement accessible afin d’en faciliter la maintenance.

You build it, you run it

Auparavant, les équipes de développement étaient en charge de produire des applications et les équipes d’administration système du maintien en condition opérationnelle de ces dernières. Désormais, l’approche DevOps recommande de faire porter aux équipes de développement la responsabilité du déploiement et de la maintenance de leurs applications. L’objectif de cette démarche est d’encourager les développeurs à en accroître la qualité et la fiabilité. Par ailleurs, ils sont les mieux placés pour réagir rapidement en cas de dysfonctionnement.

Concernant les équipes d’administration, elles se positionnent dorénavant en fournisseurs de services d’infrastructure pour les équipes de développement et peuvent se concentrer sur des tâches à plus haute valeur ajoutée. De fait, elles sont naturellement en charge de fournir aux développeurs les outils et les méthodes dont ils ont besoin pour faciliter le déploiement de leurs applications.

Feature Teams

La démarche DevOps préconise la mise en place d’équipes pluridisciplinaires regroupées par périmètre fonctionnel plutôt que par cœur de métier et suggérées. Par exemple, une équipe contenant des administrateurs systèmes et des développeurs sera dédiée à une application. De cette façon, la collaboration en vue d’atteindre un objectif commun s’en trouve optimisée. De même, lorsqu’un problème prioritaire survient, il est plus facile de mobiliser toutes les compétences nécessaires. Enfin, de cette manière, la montée en compétences des membres de l’équipe est accélérée puisque chacun peut faire profiter les autres de son expertise.

Test early, test always

Les tests doivent être pratiqués le plus en amont possible dans le processus de développement de l’application. En effet, plus une erreur est détectée tôt, moins elle sera coûteuse à corriger. Il est par ailleurs également conseillé d’automatiser l’exécution des tests à chaque modification du code.

Release early, release often

Il est recommandé de se confronter tôt aux problématiques de déploiement et de procéder à un déploiement régulier car la répétition même contribue à la fiabilisation du processus. De même, le fait de déployer régulièrement permet d’éviter de pousser trop de changements à la fois et facilite le diagnostic en cas de problème.

Intégration continue

Disposer d’un système d’intégration est indispensable dans le cadre d’une démarche DevOps. Il permet, à chaque modification du code source, d’exécuter un certain nombre d’actions de façon automatique. Parmi les actions les plus courantes, on trouve la compilation du code, les tests unitaires et d’intégration, l’analyse statique et le packaging de l’application. Ces actions sont exécutées séquentiellement par ordre de dépendance de sorte que la série d’action soit interrompue à la première erreur. Ainsi, il est inutile de procéder au packaging d’une application qui n’a pas passé les tests. Ce type d’outils dispose d’une interface visuelle et vous permet dans la plupart des cas de mettre en place un système de notification en cas d’erreur.

Gestion d’artefacts

Dans le but de garantir la reproductibilité des déploiements mais aussi de pouvoir revenir à une version antérieure en cas de dysfonctionnement, il est important de faire appel à un outil de gestion d’artefacts. Il vous permet de stocker vos applications packagées et de conserver un historique des versions précédentes.

Environnements de tests

Un soin particulier doit être accordé à la gestion des environnements de tests. Ces derniers doivent être les plus proches possibles de l’environnement de production. De plus, il peut être nécessaire de disposer de plusieurs environnements correspondants à plusieurs niveaux de maturité de l’application. A fortiori si l’application a vocation à être déployée sur plusieurs environnements de production distincts. Il sera alors nécessaire de valider son bon fonctionnement dans chacun d’entre eux. Dans l’idéal, les environnements de tests devront être disponibles et déployés à la demande par le système d’intégration continue.

Workflow Git

Le choix d’un workflow Git correspondant aux processus en place dans l’équipe est une étape importante de l’adoption d’une démarche DevOps. Puisque les modifications apportées au code source déclenchent le système d’intégration continue, il peut être intéressant de donner du sens à l’organisation de vos dépôts de code. Par exemple, chaque fonctionnalité en cours de développement sera développée dans une branche à part, et donnera lieu à l’exécution des tests et de l’analyse statique. La version de développement, quant à elle, sera déployée automatiquement dans un environnement de tests. Enfin, un tag portant un numéro de version donnera lieu au packaging d’une nouvelle version et éventuellement à son déploiement en production.

Revues de code

Les revues de code ne relèvent pas à proprement parler d’une approche DevOps. Cependant, elles ont un impact indiscutable sur la qualité du code et constituent un vecteur important de partage des connaissances, en particulier au sein d’équipes pluridisciplinaires. Elles peuvent être basées sur la bonne volonté des membres de l’équipe ou encore être imposées comme prérequis obligatoires à toute modification.

ChatOps

Les outils de chat tels que Slack ou Mattermost sont très répandus en entreprise et peuvent s’avérer très utiles pour servir de canal de notification aux systèmes d’intégration continue. Ils peuvent également, lorsqu’ils sont associés à ChatOps, permettre de déclencher un certain nombre d’opérations de façon automatisée telles que le déploiement d’un environnement de tests.

DevOps et micro-services

Une architecture micro-services consiste à la découper en composants de petite taille dédiés à une tâche. Ce type d’infrastructure est un très bon complément à une démarche DevOps à la fois parce que chaque composant est plus facile à comprendre, à tester et à maintenir, mais aussi parce qu’il est plus simple à déployer de façon automatisée sans interruption de service. Le découpage en micro-services doit être adapté en fonction des besoins et sans excès. Pourquoi ? Parce que plus on découpe en applications de services de petite taille, plus la complexité de l’infrastructure augmente.

DevOps en conteneurs

Les conteneurs sont de très bons supports pour les micro-services. Ils sont faciles à réaliser, peuvent être versionnés et, dans certains cas, peuvent même remplacer le packaging de l’application. Par ailleurs, ils offrent l’intérêt d’être peu dépendants de leur environnement d’exécution. En conséquence, ils permettent alors de construire facilement des environnements de tests proches des environnements de production.

DevOps et Cloud

Les fournisseurs de cloud fournissent aux entreprises des services à la demande qui leur permettent de s’affranchir de la gestion de leur infrastructure. Il s’agit d’un gain conséquent en termes d’agilité, même si son coût est non négligeable. Par ailleurs, la plupart des fournisseurs de cloud proposent des systèmes d’orchestration de conteneurs managés de sorte que les entreprises qui construisent leurs applications sous forme de conteneurs sont en mesure de les déployer facilement auprès de n’importe quel fournisseur.