Aujourd’hui, la survie des entreprises est plus que jamais déterminée par la capacité à produire des applications toujours plus innovantes, susceptibles de plaire à des utilisateurs de plus en plus exigeants...
Divers mouvements ont contribué à la création de DevOps. Tout d’abord, le mouvement Lean dont l’origine est le système de production, inventé dans les années 80 par le constructeur Toyota, le Toyota Production System (TPS). Ce système est centré sur l’amélioration continue de la valeur délivrée, par l’élimination des gaspillages. TPS généralise la pratique de la qualité à la source, ainsi que la gestion scientifique des flux de livraison des produits dans les chaînes de production. Lean a apporté à DevOps de nombreuses pratiques intéressantes, comme le Value Stream Mapping (la visualisation des flux de livraison logicielle) ou les tableaux de Kanban.
Ensuite, il y a le mouvement Agile en 2001, dont l’un des principes fondamentaux est de livrer des logiciels qui marchent, beaucoup plus fréquemment, sur des périodes courtes, les sprints (environ d’un mois). On peut noter deux apports essentiels du mouvement Agile à Devops : premièrement, la fourniture des livraisons logicielles en petits lots, fréquemment, de manière incrémentale, plutôt que des larges livraisons logicielles des cycles projet en V. Les apports du mouvement Agile se sont enrichis dans les années 2008 avec le « Velocity Mouvement » qui a introduit les principes de « Continuous Integration » et « Continuous Delivery », CI/CD. Ces principes ont industrialisé les activités de développement logiciel en faisant reposer les développements sur des infrastructures de livraison logicielle complètement automatisées. Ces innovations ont considérablement augmenté la qualité et les cadences des livraisons en production. Parmi les personnes ayant le plus contribué à la naissance de DevOps, on peut citer Patrick Debois, Gene Kim, John Willis, et Alanna Brown, auteurs de nombreux ouvrages et conférences comme les DevOpsDays.
Le terme DevOps lui-même a été introduit en 2009 en Belgique par Patrick Debois aux premiers DevOpsDays, pour désigner plus simplement le nouveau mouvement qui venait de naître de l’association de Dev et Ops. Sous-entendu un ensemble des meilleurs pratiques de développement informatique (Dev) et d'exploitation en production (Ops) enveloppés dans nouvelle culture organisationnelle.
De nos jours, chaque logiciel d’entreprise doit apporter un maximum de
bienfaits pour un minimum de temps et d’effort. Par exemple, vous avez sans
doute vu comment l’approche Agile a révolutionné l’informatique. Elle accélère
la livraison de chaque nouvelle version d’un logiciel en raccourcissant les
cycles de développement.
Il manquait cependant une synergie entre les activités de développement et celles
des opérations. Trop souvent, les deux équipes travaillaient chacune isolée
dans son silo. Les logiciels étaient développés sans considération des
contraintes opérationnelles. L’équipe des opérations devait se débrouiller
seule pour faire fonctionner les applications dans le monde réel. Les surcroîts
de travail et la frustration étaient fréquents.
DevOps résout ce problème en faisant collaborer des développeurs et des ingénieurs des opérations et en étendant les avantages de la méthode Agile à tout le cycle de vie du logiciel. Ainsi, votre logiciel est conçu dès le début pour fonctionner dans la vraie vie. La souplesse et la rapidité du cycle de vie vous permet de réagir facilement à des environnements ou des objectifs changeants. Avec DevOps, votre logiciel apporte beaucoup plus de valeur, plus rapidement, plus sûrement, et plus fréquemment.
DevOps repose sur trois principes directeurs :
A ces principes, se rajoutent un élément fondamental à instaurer dans la culture organisationnelle: l’élimination de toute culture du blâme face aux erreurs que pourraient commettre les personnes dans l’accomplissement de leurs missions : ex. les erreurs conduisant à des incidents en production, ou tout simplement les omissions dans le cycle de développement.
Mais DevOps dépend surtout de la collaboration profonde entre les développeurs (dev) et les ops, plus largement entre toutes les parties prenantes des projets logiciels, y compris les Business Owner.
Cette coopération est soutenue par les bons processus et les bonnes pratiques. Elle est renforcée et facilitée par des outils qui automatisent à outrance les tâches répétitives, ou sujettes aux erreurs humaines fréquentes.
Il ne faut donc pas s’attendre à ce que les outils fassent seuls le travail. Le succès en DevOps viendra d’abord de l’adoption d’une culture d’entreprise appropriée, celle qui remet la coopération humaine au centre, qui élimine le blâme et promeut l'apprentissage continu .
DevOps apporte rapidité, fiabilité et sécurité dans les productions de releases informatiques. Selon le rapport 2019 State of DevOps, les organisations les plus performantes réalisent :
DevOps, en plus d’accroître le rythme des livraisons, améliore la qualité des release logicielles. En outre les services informatiques gagnent nettement en stabilité, et les équipes en coopération.
Selon le rapport 2020 du State of DevOps, 75% des entreprises ayant un haut niveau de maturité DevOps, arrivent à remédier aux vulnérabilités de sécurité en moins d’une journée. Ce qui montre l’adéquation de cette pratique avec l’autre grand défi de l’économie digitale, la Cybersécurité.
Le fonctionnement de DevOps repose sur des pratiques à adapter à chaque contexte d’entreprise :
La mise en œuvre de DevOps dans une entreprise dépend fortement du contexte de l’entreprise. Il n’existe pas de méthode unique s’appliquant à tous. Par exemple dans l’univers Francophone, la culture d'entreprise est encore fortement centralisée. Les marqueurs du Jacobisme restent présents malgré tout, notamment dans les plus grandes entreprises. Cette forte concentration de pouvoir au niveau d’un management centralisé, très en haut de la pyramide représente souvent un obstacle de taille dans l’adoption de DevOps.
C'est pourquoi, dans ce type de contexte, l'approbation managériale au plus haut niveau hiérarchique de
l’entreprise est pré-requis à toute transformation DevOps.
En effet, DevOps a des conséquences non négligeables pour le management. On, peut citer par exemple le fait que l’autonomie des squads au niveau de la prise de décisions opérationnelles, implique une modification profonde des attributions du manageur tel qu’il a toujours été. Ensuite, et plus concrètement, l'adoption de DevOps comportera des phases incontournables eu égard à l'expérience de nombreuses entreprises:
Dans tous les cas, la mise en œuvre de DevOps dans l’entreprise doit se faire par des étapes contrôlées de manière à rassurer l'ogranisation. Le succès d’un projet pilote est toujours une excellente référence, qui bénéficie de soutiens plus nombreux qui faciliterons une généralisation la pratique au sein de toute l’organisation.
En 2018, le rapport « State of DevOps » de circleci a établi 5 niveaux de maturité, relatifs à l’adoption de DevOps dans les organisations. Il s’agit d’une projection d’étapes cohérentes permettant non seulement de situer son organisation du point de vue DevOps, mais aussi de construire sa trajectoire d’évolution vers la prochaine étape à atteindre.
Niveaux |
Résultats |
Niveau 1 « Normalisation » |
|
Niveau 2 « Standardisation » |
|
Niveau 3 « Expansion » |
|
Niveau 4 « Infrastructure automatisée » |
|
Niveau 5 « Self-Service» |
|
Le Cloud est très vite devenu le standard de l’informatique. A peu près tout ce qui se code comme applications, l’est aujourd’hui dans le Cloud. D’ailleurs DevOps est né, et s’est développé chez les GAFAM (Google, Apple, Facebook, Microsoft). Ça a été l’un des facteurs leur ayant permis de construire aussi rapidement, les larges infrastructures informatiques que nous connaissons.
Microsoft propose un Cloud dénommé Azure, Amazon le Cloud AWS (Amazon Web Services) et Google le GCP (Google Cloud Platform).
Pour accélérer les souscriptions de services dans leurs Cloud respectifs, ces Cloud Providers ont mis en place des plateformes qui automatisent les créations et l’exploitation de leurs services informatiques. Ainsi, chaque Cloud Provider propose une plateforme taillée sur mesure pour ses environnements, fournissant des outils sur étagère pour la gestion de projet agile, l’intégration continue Ci/Cd, l’Infrastructure As Code (IaaC) et la Configuration as Code (CaC).
Ces plateformes ne couvrent que les aspects techniques de DevOps, les adopter seuls ne suffit à profiter complètement des bénéfices attendus d'une transformation DevOps. En particulier, la culture de l’organisation, et la pratique de l’apprentissage continue dans les équipes, restent des points déterminants pour réussir DevOps.
Le tout technologique dans les mains d'un seul Cloud Provider ne couvre pas non plus tous les scénarios de construction d’infrastructures automatisées. Il n’est pas rare de devoir y ajouter des outils externes open source pour palier aux limitations d'un Cloud Provider donné, par exemple au niveau de Configuration as à Code, du monitoring ou de la sécurité.
De plus, les technologies des Cloud Provider restent propriétaires, ce qui peut devenir un obstacle dans certaines situations, en particulier lorsque les services informatiques consommés sont distribués sur différents Cloud Providers (pas dans un seul), doivent inter-opérer.
Azure DevOps est la plateforme de Microsoft pour les services du Cloud Azure, elle comprend, les outils suivants :
Côté Amazon, AWS DevOps en comparaison offre les services ci-dessous:
Chez Google Cloud Platform (GCP), des services similaires sont offerts, notamment:
La culture et les principes de DevOps sont plus durables que des technologies qui elles évoluent sans cesse. Cependant, l’outillage occupe une place centrale dans les pratiques DevOps notamment pour l’automatisation des tâches dans les développements logiciels.
Avec l’arrivée de DevOps une profusion d’outillages a vu le jour essentiellement dans l’open source. Les exemples d’outils les plus courants, classés par catégorie sont les suivants :
Une excellente source de connaissances des outils DevOps initialement construite par la société Française XebiaLabs, depuis devenue digitalai. Elle se nomme « le tableau périodique de classification DevOps" en référence au tableau périodique des éléments chimiques de Mendeleïev pour faire le parallèle avec les sciences. Ce tableau organise chaque outil en fonction de son usage dans DevOps de manière visuelle. L’exploration de ce tableau est consultable ici "Tableau périodique des outils DevOps".
Le rôle central de l’intégration et la livraison continue
L’intégration et la livraison continue sont d’une importance centrale dans DevOps. Ces deux pratiques vous assurent (jusqu’à plusieurs fois par jour) que les différents paquets de code fonctionnent correctement ensemble et peuvent être déployés comme il faut. Avec le pipeline CI/CD :
Regardons de plus près la dimension humaine de DevOps, sans laquelle les outils et les processus seraient inutiles. Les entreprises informatiques, comme celles d’autres secteurs ont toujours fonctionné sur un modèle organisé en « divisions » ou silos. L’une des conséquences a été l’hyperspécialisation des ingénieurs sur chaque activité ou composant de l’infrastructure informatique sur lequel ils intervenaient. Une séparation claire était opérée entre les fonctions de type "Build", côté développements, et les fonctions de type "Run" consacrées à l'exploitation en production. Il était courant de voir dans les entreprises des profils possédant des expertises exclusives sur un élément de l’infrastructure : Ainsi un développeur en langage, C ou Java, ne savait faire que cela, et pour déployer un logiciel, il devait livrer son code à d’autres ingénieurs, maîtrisant uniquement le système d’accueil du code de l’application, mais n’ayant aucune compétence en codage.
Il n’était pas rare de faire de longues carrières dans des rôles d’ingénieur spécialisés comme les ingénieurs base de données (PostgreSQL, Oracle, etc.), ou des rôles d'ingénieur réseau spécialisés Cisco, réseau Juniper, ou des rôles d’ingénieur système linux, des rôles d’ingénieur infra VMWARE, des rôles de développeur php ..., la liste des spécialités est longue.
A la différence de cela, les ingénieurs DevOps arrivent avec des compétences complètement nouvelles. Ils définissent un nouveau standard du rôle d'ingénieur informatique reposant sur l’association de multiples compétences codage et système en un seul et même rôle. Les ingénieurs DevOps doivent disposer dans l’idéal de plusieurs savoir-faire notamment :
Pour évoluer dans des organisations productives, dont la culture est plutôt
transverse, l’ingénieur DevOps doit disposer d’une forte capacité à
collaborer, d'un goût de l’apprentissage, ainsi que d’excellentes qualités de
communication.
Le paysage informatique des entreprises subit des changements profonds. Le Cloud ("L’infonuagique") prend le dessus sur quasiment toutes les constructions actuelles de productions informatiques. Les postes d’ingénieur système, ingénieur réseau, et autres sont en train de se transformer ou d’être remplacés à terme, par exemple, par des rôles de DevOps.
Parmi les attraits du « métier » de DevOps on peut retenir :
Qu’ils soient à l’origine des développeurs qui s’orientaient vers les opérations ou des administrateurs de système qui s’intéressaient à la programmation, les bons ingénieurs DevOps ont en commun:
Les fonctions d'encadrement informatique des entreprises sont en première ligne pour réussir une adoption de DevOps et en tirer les bénéfices attendus. Pour les Responsables Informatiques des PME et ETI, ou les Manageurs IT des grands groupes, le principal enjeu de l'adoption de DevOps, est d'être capables de communiquer avec leurs équipes. En effet, ces derniers parlent de nouveaux langages propres aux innombrables technologies souvent méconnues de leurs manageurs. Il en est de même des professionnels informatiques assurant des rôles de coordination et de pilotage comme les Product Owner, les Chef de Projet ou les Scrum Master, qui assument l'encadrement immédiat des équipes. Si elles manquent de connaissances de base sur les concepts fondamentaux de DevOps, cela devient vite un handicap pénalisant leur capacité à se faire comprendre, à animer et à diriger convenablement leurs équipes.
En outre, leur légitimité vis-à-vis des personnes dans les éuiqpes DevOps (les squads) peut être rapidement être remise en cause. L'atteinte des objectifs d'amélioration de flux d'activité attendus de l’adoption de DevOps dans une organisation, peuvent s’en trouver compromis en raison des faibles compétences des lignes managériales sur le sujet.
Avec la pratique de l'intégration continue (pipelines ci/cd), et la généralisation du cloud, il devient impossible d'assurer un pilotage pertinent des activités en se basant sur les méthodes de reporting anciennes. En cause une trop grande multiplicité des sources, et d'informations à analyser.
DevOps introduit le monitoring continu de la chaîne de développement, des infrastructures de création de service, ainsi que des applications en production.
Pour l'encadrement cette surveillance passe par la mise en place de nouveaux moyens d'analyse offrant une meilleure visibilité sur les problèmes.
Le bon vieux reporting PowerPoint sera remplacé par des outils de datavisualisation alimentés continuellement et capable de fournir une analyse managériale pertinente sur trois niveaux :
Voici quelques idées préconçues à savoir pour éviter les pièges dans la compréhension DevOps. Certaines sont tirées du livre « The DevOps Handbook » écrit par Gene Kim, Jez Humble, Patrick Debois et John Willis.
« DevOps ce sont les technologies telles qu’Azure DevOps, Jenkins, AWS DevOps etc »
Le seul emploi des technologies est insuffisant pour réussir sa transformation DevOps. DevOps c’est l’ensemble interreliés de la culture d’entreprise "Blameless", des principes et des pratiques d'automatisation. Les outils ne sont qu’une composante dont la mise en œuvre vient soutenir cette nouvelle culture. Nombre d’entreprises ne connaissent pas d’améliorations après une transformation consistant uniquement à intégrer de nouveaux outils d'automatisation notamment chez des Cloud Provider. Il en est de même des professionnels se destinant à des carrières dans DevOps, qui ne s’intéressent qu’à l’acquisition de compétences techniques sur des outils. Une maîtrise plus large des concepts DevOps donnera au professionnel des atouts intellectuels nécessaires pour s’adapter durablement dans un univers technologique en perpétuel changement.
« DevOps c’est le remplaçant de la méthode Agile »
DevOps ne remplace pas, mais est plutôt la continuation du mouvement Agile,
en ce sens qu’il prolonge l’association du Product Owner et du Développeur en y
intégrant les Ops.
« DevOps c’est uniquement pour les startUps »
De très grandes entreprises comme Google, Netflix emploient massivement
DevOps dans leur organisation. Elles ont toutes rencontré à un moment de leur
histoire, des limites à leur développement en raison de pratiques anciennes
dans leurs informatiques (projets en cycle en V, codes complexes et larges
livraisons de releases). DevOps a justement été pour ces grandes entreprises, l’enabler de leur passage à l’échelle de très grandes
entreprises planétaires que nous connaissons aujourd’hui.