Salut Habr ! Je présente à votre attention la traduction de l'article « Les origines du DevOps : qu'y a-t-il dans un nom ? » par Steve Mezak.

Selon votre point de vue, DevOps fêtera cette année son neuvième ou dixième anniversaire. En 2016, le rapport State of the Cloud de RightScales indiquait que 70 % des PME adoptaient des pratiques DevOps. Chaque indicateur qui compose ce score a augmenté depuis. Alors que DevOps se prépare à entrer dans sa deuxième décennie, il serait formidable de faire un retour dans le passé et de revenir aux origines de DevOps, et même aux origines du nom lui-même.

Avant 2007 : un enchaînement parfait d’événements

Avant 2007, une série de circonstances ont finalement donné naissance à ce que l’on appelle aujourd’hui DevOps.

Maigre s'est déjà révélé être une bonne pratique. Aussi connu sous le nom Système de production Toyota, Lean Manufacturing s'efforce d'optimiser les processus dans l'atelier de fabrication. (D'ailleurs, la direction de Toyota s'est initialement inspirée des méthodes originales de chaîne de montage introduites par Ford Motor Company). Amélioration continue est le mantra de la production au plus juste. En pratique, les parcours suivants sont constamment évalués :

1. Maintenir les niveaux de stocks de matières premières et de produits finis au minimum. La fabrication au plus juste signifie une quantité minimale de stocks de matières premières pour produire des biens et une quantité minimale de produits finis en attente d'être commandés ou expédiés.
2. Minimiser la file d’attente des commandes. Idéalement, les commandes reçues passent immédiatement à l’état terminé. La mesure clé du Lean Manufacturing sera toujours le temps écoulé entre la réception de la commande et la livraison.
3. Maximiser l’efficacité du processus de production. La réingénierie des processus et l’amélioration de l’automatisation se combinent pour produire des biens le plus rapidement possible. Chaque domaine de production tout au long du parcours (découpe, soudage, assemblage, tests, etc.) est évalué pour déceler ses inefficacités.

Dans le monde informatique, les méthodes traditionnelles du modèle de développement logiciel en cascade ont déjà cédé la place à des méthodes itératives rapides telles que Agile. La rapidité était le cri de ralliement, même si la qualité souffrait parfois dans la poursuite d'un développement et d'un déploiement rapides. De la même manière, le cloud computing, en particulier Infrastructure en tant que Service (IaaS) et Plateforme en tant que service (PaaS) se sont révélés être des solutions matures en matière de processus et d'infrastructures informatiques.

Enfin, des boîtes à outils ont récemment commencé à apparaître pour Intégration continue (CI). L'idée des outils CI est née et présentée par Gradi Booch en 1991 dans sa méthode Booch.

2007-2008 : Belge déçu

Patrick Debois, consultant belge, responsable de projet et de pratique Agile, a accepté une nomination d'un ministère du gouvernement belge pour aider à la migration des centres de données. Il a notamment participé aux tests de certification et de préparation. Ses responsabilités l'obligeaient à coordonner et à établir des relations entre les équipes de développement de logiciels et les équipes d'exploitation des serveurs, des bases de données et des réseaux. Sa frustration face au manque de cohésion et aux murs qui séparent les méthodes de développement et d'exploitation le laisse amer. Le désir de s'améliorer de Desbois l'a rapidement amené à l'action.
Lors de la conférence Agile de 2008 à Toronto, Andrew Schaefer a proposé de modérer une réunion informelle spécialement organisée pour discuter du sujet "Infrastructure agile"Et une seule personne est venue discuter du sujet : Patrick DeBois. Leur discussion et leur échange d'idées ont fait progresser le concept d'administration de systèmes Agile. La même année, DeBois et Schaefer ont créé le groupe Agile Systems Administrator chez Google, avec un succès modéré.

2009 : Le cas de la coopération entre Dev et Ops

Lors de la conférence O'Reilly Velocity, deux employés de Flickr, le vice-président principal des opérations techniques John Allspaw et le directeur technique Paul Hammond, ont donné la désormais célèbre présentation. "10 déploiements par jour : collaboration entre développeurs et opérateurs sur Flickr".

La présentation était un drame, avec Allspaw et Hammond reconstituant les interactions complexes entre les représentants du développement et des opérations pendant le processus de déploiement du logiciel, avec des accusations et des récriminations du type « Ce n'est pas mon code, c'est tous vos ordinateurs ! Leur présentation a confirmé que la seule option sensée est que les activités de développement et de déploiement de logiciels soient transparentes et pleinement intégrées. Au fil du temps, cette présentation est devenue légendaire et est désormais historiquement considérée comme une étape décisive lorsque l'industrie informatique a commencé à réclamer la méthodologie connue aujourd'hui sous le nom de DevOps.

2010 : DevOps aux États-Unis d'Amérique

Avec un public croissant, la conférence DevOpsDays s'est tenue pour la première fois aux États-Unis à Mountain View, en Californie, immédiatement après la conférence annuelle Velocity. Avance rapide jusqu'en 2018, et plus de 30 conférences DevOpsDays sont programmées, dont des dizaines aux États-Unis.

2013 : Projet « Phénix »

Pour beaucoup d’entre nous, un autre moment marquant dans l’histoire du DevOps a été la publication du livre « The Phoenix Project » de Gene Kim, Kevin Behr et George Safford. Ce roman raconte l'histoire d'un responsable informatique qui se retrouve dans une situation désespérée : il est chargé de sauver un projet de commerce électronique critique qui a mal tourné. Le mystérieux mentor du manager - un membre du conseil d'administration passionné par les méthodes de production Lean - suggère au personnage principal de nouvelles façons de penser l'informatique et le développement d'applications, anticipant le concept de DevOps. À propos, « The Phoenix Project » nous a inspiré le livre « Outsource or else... » sur une histoire commerciale similaire dans laquelle un vice-président des logiciels utilise DevOps lors du développement d'un nouveau produit externalisé majeur.

DevOps pour l'avenir

Il vaut la peine de décrire DevOps comme un voyage, ou peut-être une aspiration, plutôt que comme une destination finale. DevOps, comme le Lean Manufacturing, vise une amélioration continue, une productivité et une efficacité accrues, voire un déploiement continu. Les outils automatisés pour prendre en charge DevOps continuent d'évoluer.

Beaucoup a été accompli depuis la création du DevOps au cours de la dernière décennie, et nous espérons en voir encore davantage en 2018 et au-delà.

Source: habr.com