Rechercher
  • Jacky Montiel

DevOps d'entreprise - Enjeux et solutions (Partie 1/2)


Le DevOps d'entreprise pose la question de l'harmonisation des pratiques et des outils DevOps à l'échelle de l'entreprise. L'objet de cette série de 2 articles est de revenir sur la notion de DevOps d'entreprise, les enjeux qu'il représente (article 1), puis de proposer une approche solution méthodologie/outils pour y répondre (article 2).



1- Le DevOps d'entreprise et les enjeux

Le DevOps tout court est aujourd'hui entré dans la culture des entreprises porté par des projets nouveaux (applications ou produits logiciels) souvent développés en méthodes agiles. L'approche est très souvent menée en 'shadow IT', c'est-à-dire en mode de gouvernance projet et non DSI. Chaque projet définit selon ses objectifs business, son processus DevOps, le pipeline d'orchestration, les outils, les divers moyens d'automatisation (tests, déploiements, ...) et la gouvernance du process (les points de contrôle pour approbation ou leur automatisation).


L'introduction du DevOps en 'Shadow IT' est un premier pas pour explorer de nouvelles pratiques et de nouveaux outils. Mais arrivé à un certain stade, l'entreprise qui traite de nombreuses applications/produits a intérêt à rationaliser l'approche DevOps pour plus d'efficacité. Il s'agit de capitaliser sur les bases acquises.


Le DevOps d’entreprise est la généralisation du DevOps à l'échelle de l'entreprise (cf Ref0 et Ref1). Les questions qui se posent sont alors :

  • comment constituer un patrimoine commun méthodes/outils

  • comment généraliser le DevOps à des applications/produits classiques : applications monolithiques, applications de type configuration/personnalisation de progiciels ou de frameworks produits (ex: Hybris eCommerce)

  • quelle gouvernance DevOps faut-il mettre en place au niveau entreprise et au niveau projet

  • comment intégrer le DevOps avec d’éventuelles procédures telles que l'ITIL, la certification ISO-9001, les process de 'realease management' déjà en place.

Plusieurs éléments sont venus s'introduire dans le contexte même du DevOps et compliquent la démarche entreprise :

  • le Cloud avec l'IaC a fait entrer l’infrastructure dans une nouvelle dimension du cycle de vie logiciel

  • de même la sécurité s'intègre dans le process avec le DevSecOps,

  • enfin le NoOps, basé sur le serverless tend à simplifier la vision infrastructure à l’extrême.

L'enjeu du DevOps d'entreprise est de réussir à intégrer tous ces éléments dans une approche cohérente et ouverte aux évolutions technologiques.


2- Retour sur les fondamentaux du DevOps

Le DevOps a longtemps souffert d'un flou de définition : est-ce une culture, une philosophie, une méthode, une organisation , un rôle, ... ? Nous n'entrerons pas dans ce débat (qui ne manquera pas d’alimenter des discussions passionnées à la machine à café), mais nous adopterons ici la définition assez courante suivante (cf. Ref3) :


"DevOps is a software development method that emphasizes communication, collaboration (information sharing and web service usage), integration, automation, and measurement of cooperation between software developers and other IT professionals. The method acknowledges the interdependence of software development, quality assurance (QA), and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance."


On fait souvent référence aux 4 principes fondamentaux du DevOps regroupés sous le sigle de CAMS :


  • Culture : partager une vision commune entre les équipes en jeu

  • Automation : créer des tâches automatisées pour accélérer les cycles (tests, déploiements)

  • Monitoring : observer l'exécution en production (infrastructure et application) pour créer des boucles de feedback rapides

  • Sharing : partager les informations et briser les silos entre les acteurs du process, mais aussi partager les responsabilités.

Le DevOps a donc comme objectif d'apporter l'agilité du développement jusqu'à l'exploitation : permettre des déploiements plus fréquents et plus rapides.

Du point de vue opérationnel, la notion de pipeline CI/CD s'est dégagée comme le stéréotype du DevOps connectant les deux univers Dev et Ops : le pipeline couvre le process simple 'Build/Test/Deploy', partie du circuit traditionnel en huit.



Dans la réalité, les choses ne sont pas aussi simples : l'organisation dépasse généralement le couple Dev et Ops et met en jeu plusieurs équipes et une gourance établissant des points de contrôle et de validation. Il faut aussi prendre le terme Test et Deploy au sens large : le déploiement ne se fait pas uniquement dans l'environnement de Prod mais dans divers autres environnement HorsPord pour les tests (Dev, Validation, Perf, PreProd).

Voici un exemple type d'organisation Equipe/Tache :

  • Dev → code, build, test-Unitaires, test-Build

  • Intégration/Ops → administration et configuration de l'infrastructure cible, déploiement vers les environnements cible HorsPord et Prod souvent le rôle Ops est tenu par des ingénieur devops

  • QA → validation en général le métier, qui est le commanditaire de l'application, spécifie et développe les tests de qualification fonctionnelle (acceptance) puis valide le passage en production selon les résultats de tests ; on a aussi à ce niveau la qualification de performance

  • Exploitation infra/Ops → monitoring et MCO de l'infrastructure de Prod cette fonction peut-être réalisée en interne ou sous-traitée à un opérateur externe qui s’appuiera sur une une couche service de type IaaS, CaaS, PaaS, SaaS en cloud public ou privé

  • Exploitation applicative → monitoring des métriques applicatives cette tâche est en général assurée par un Responsable d'application métier qui surveille le comportement de l'application à travers des métriques ; le monitoring applicatif peut aussi être réalisé avec des outils d'APM qui remontent des traces (AppDynamics, Dynatrace, DataDog, ....) -------

et en transverse

  • Sécurité → définition des moyens, procédures, outils à intégrer dans le process pour limiter les vulnérabilités avant déploiement, surveillance des applications en exploitation pour détecter des attaques, cloisonnement réseau des composants pour limiter la propagation des attaques.

Bien qu'il soit impossible de décrire tous les cas de figure en un seul schéma, voici en vue macro un exemple d'organisation réunissant ces équipes :

Un pipeline DevOps complet doit donc intégrer l'intégration continue (CI), la délivrance continue (CDelivery) vers les environnements HorsProd, le déploiement coninu (CDeployement) vers la Prod et la gestion d'infrastructure en IaC.


3- Vers un DevOps d'entreprise

A l'échelle de l'entreprise, adopter une approche fédératrice peut se heurter aux habitudes déjà acquises. Il faut tenir compte de l'actif pour proposer une réponse structurée à laquelle tous les acteurs doivent pouvoir adhérer et contribuer.


Une stratégie DevOps d'entreprise reposera donc sur 3 piliers :

  1. une méthodologie DevOps applicable à l'ensemble des projets de l’entreprise,

  2. un référentiel outils DevOps pour orienter les projets vers des outils reconnus, en nombre limités et avec des mode opératoires prêt à l'emploi

  3. une gouvernance DevOps au sein de l'entreprise, s'appuyant sur une communauté DevOps de partage

Dans un prochain article nous présenterons des solutions pour mettre en oeuvre une telle stratégie.


Références :

77 vues0 commentaire

Posts récents

Voir tout