DevOps, vous avez dit DevOps ?

Cet article se veut un petit guide visant à définir le DevOps ainsi que la façon dont il est implémenté au quotidien en entreprise. Il s'adresse particulièrement à celles et à ceux qui ont une vision encore floue de ce qu'est le DevOps et de ce qu'il implique. C'est pourquoi j’ai volontairement tenté de faire abstraction de la technique dans la mesure du possible.

Histoire du DevOps

De nos jours, le terme DevOps est au centre de toutes les attentions. Tout le monde en parle et pourtant, il règne encore une certaine confusion autour de sa définition. Employé pour désigner une personne, le fameux « ingénieur devops », ou un ensemble d’outils, il est bien souvent réduit au simple périmètre de l’intégration continue ou de l’automatisation.

Afin d’obtenir une vision plus claire de ce qu’est le DevOps, il convient de se pencher plus en détail sur la situation à l’origine de son invention.

 

Aux origines du DevOps

Traditionnellement, au sein d’un système d’information, on trouve deux types de protagonistes clairement identifiés :

• Les équipes de développement d’une part,
• Et les équipes en charge de l’administration système, d’autre part.

Ces deux catégories sont généralement séparées tant d’un point de vue géographique que managérial. Chacune fait face à des contraintes de budget et de temps, et cherche à atteindre ses propres objectifs. Malheureusement, depuis près d’une quinzaine d’années, avec l’accélération de l’innovation dans le domaine de l’informatique, ces objectifs tendent à s’opposer.

En effet, le rôle des équipes de développement consiste à livrer des fonctionnalités dans un temps imparti alors que les équipes d’exploitation sont chargées de s’assurer du bon état de fonctionnement du système et de sa stabilité dans le temps. Cet antagonisme est générateur de stress, voire de conflit, et peut avoir de graves conséquences portant atteinte à la rentabilité et à l’image de l’entreprise.

Partant de ce constat, en 2008, certains membres de la mouvance agile tels que Patrick Debois et Andrew Shafer ont cherché à appliquer les préceptes de l’agilité bien connus des développeurs à la branche infrastructure des systèmes d’information. On parle alors d’« agile infrastructure ». Un an plus tard, lors de la première conférence « DevOpsDays » à Gand, en Belgique, Patrick Debois emploie pour la première fois le terme DevOps.

Le mouvement DevOps n’a jamais vraiment abouti à une formalisation stricte contrairement aux méthodes agiles. Cependant, ses principes fondateurs visant à fluidifier les interactions entre développement et exploitation sont largement adoptés en entreprise.

 

Les concepts fondamentaux

 

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

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.

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.

 

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.

 

Les bonnes pratiques du DevOps

 

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.

 

Everything as code

Le fonctionnement d’une application fait en général intervenir un certain nombre d’outils ou d’autres applications. Stocker la configuration de ses outils au sein du code source de votre application permet d’appliquer la même démarche d’amélioration continue à la configuration de votre infrastructure qu’à votre application. Par exemple, il est possible de décrire les pipelines d’intégration continue ou encore l’infrastructure cible sous forme de fichiers de configuration.

 

Implémentation

 

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.

 

Références

 

Bibliographie

Wikipedia (en)
Wikipedia (fr)
DevOps for Dummies (IBM Limited Edition)
DevOps for Dummies (3rd IBM Limited Edition)
Git flow Cheat Sheet

Humour

The Bastard Operator From Hell
XKCD – Devotion To Duty
XKCD – Automation
XKCD – Tools

Laisser un commentaire

MERITIS ICI. ET LÀ.

Carte Meritis

Meritis Finance

5 – 7, rue d’Athènes
75009 Paris

+33 (0) 1 86 95 55 00

contact@meritis.fr

Meritis PACA

Les Algorithmes – Aristote B
2000 Route des Lucioles
06901  Sophia Antipolis Cedex

+33 (0) 4 22 46 31 00

contact@meritis-paca.fr

Europarc de Pichaury – Bâtiment B5
13290 Aix-en-Provence

+33 (0) 4 22 46 31 00

contact@meritis-paca.fr

Meritis Technologies

5 – 7, rue d’Athènes
75009 Paris

contact@meritis-technologies.fr

+33 (0) 1 86 95 55 00


Contactez-nous

Pour connaître et exercer vos droits, concernant l'utilisation des données collectées par ce formulaire, veuillez consulter la page sur notre politique de confidentialité.