Bonjour Habr ! Je vous présente la traduction de l'article auteur Steve Mezak.
Selon votre point de vue, DevOps célébrera cette année son neuvième ou dixième anniversaire. En 2016, le rapport de RightScale sur l'état du cloud indiquait que 70 % des petites et moyennes entreprises adoptaient les méthodes DevOps. Chaque indicateur de cette évaluation a depuis augmenté. Alors que DevOps se prépare à entrer dans sa deuxième décennie, il serait intéressant de parcourir les méandres du passé et de revenir aux origines de DevOps — et même à l'origine de ce nom lui-même.
Avant 2007 : Une chaîne d'événements idéale
Avant 2007, une série de circonstances a finalement donné naissance à ce que l'on connaît aujourd'hui sous le nom de DevOps.
La production lean s'est déjà imposée comme une meilleure pratique. Également connue sous le nom de système de production Toyota,la production lean vise à optimiser les processus dans l'atelier de production. (Au fait, la direction de Toyota a été initialement inspirée par les méthodes de la chaîne de montage présentées par Ford Motor Company). L'amélioration continue est un mantra pour la production lean. En pratique, les voies suivantes sont constamment évaluées :
- Maintenir les niveaux d'inventaire de matières premières et de produits finis au minimum.La production lean signifie un minimum de matières premières pour la fabrication de produits et un minimum de produits finis en attente de distribution selon les commandes ou de livraison.
- Minimisation des files d'attente des commandes.Idéalement, les commandes reçues passent immédiatement à l'état de terminées. La principale métrique de la production lean sera toujours le temps écoulé entre la réception de la commande et la livraison.
- Maximisation de l'efficacité des processus de production.La réorganisation des processus et l'automatisation améliorée se combinent dans le but de produire des biens aussi rapidement que possible. Chaque étape de production tout au long du parcours (découpe, soudage, assemblage, test, etc.) est examinée pour détecter les inefficacités.
Dans le monde de l'informatique, les méthodes traditionnelles du modèle en cascade pour le développement de logiciels ont déjà cédé la place à des méthodes itératives rapides, telles que Agile. La rapidité était un cri de guerre, même si la qualité diminuait parfois dans la course vers un développement et un déploiement rapides. C'est à peu près ainsi que l'informatique cloud, en particulier Infrastructure en tant que Service (IaaS) et Plateforme en tant que Service (PaaS) ont fait leurs preuves en tant que solutions matures dans les processus et l'infrastructure IT.
Enfin, des ensembles d'outils pour Intégration Continue (CI) ont récemment commencé à apparaître. La notion d'outils CI a été introduite et présentée par Grady Booch en 1991 dans sa méthode Booch.
2007-2008 : Un Belge déçu
Le consultant belge, chef de projet et praticien Agile Patrick Debois a été nommé par le ministère du gouvernement belge pour aider à la migration des centres de données. En particulier, il s'occupait de la certification et de la vérification de la préparation. Ses responsabilités l'obligeaient à synchroniser les actions et à établir des relations entre les équipes de développement logiciel et les équipes d'exploitation serveurs, de bases de données et de réseaux. Son désarroi face à l'absence de cohésion et aux murs séparant les méthodes de développement et d'exploitation lui a causé de la frustration. Son désir d'amélioration a bientôt conduit Debois à l'action.
En 2008, lors de la conférence Agile à Toronto, Andrew Shafer a proposé de modérer une rencontre 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 l'échange d'idées ont avancé le concept de l'administration système Agile. Cette même année, Debois et Shafer ont créé un groupe de travail Agile Systems Administrator modérément réussi sur Google.
2009 : L'affaire de la collaboration entre Dev et Ops
Lors de la conférence O'Reilly Velocity, deux employés de Flickr, le vice-président senior des opérations techniques John Allspaw et le directeur technique Paul Hammond, ont présenté la désormais célèbre présentation « 10 déploiements par jour : la collaboration entre Dev et Ops chez Flickr ».
La présentation était de style dramatique, Allspaw et Hammond ont joué une interaction complexe entre les représentants du développement et des opérations lors du déploiement de logiciels, tout en cherchant des coupables et en se lançant des accusations dans l'esprit de "Ce n'est pas mon code, ce sont tous vos ordinateurs !" Leur présentation a confirmé que la seule sortie raisonnable consiste à rendre les activités de développement et de déploiement de logiciels fluides, transparentes et entièrement intégrées. Au fil du temps, cette présentation est devenue légendaire et est désormais considérée comme une étape fondamentale lorsque l'industrie informatique a exprimé un besoin pour la méthodologie connue aujourd'hui sous le nom de DevOps.
2010 : DevOps aux États-Unis
Avec l'augmentation du nombre de partisans, la conférence DevOpsDays a été organisée pour la première fois aux États-Unis à Mountain View (Californie) immédiatement après la conférence annuelle Velocity. Projetons-nous en 2018 : plus de 30 conférences DevOpsDays sont prévues, y compris des dizaines aux États-Unis.
2013 : Projet Phoenix
Pour beaucoup d'entre nous, un autre moment marquant dans l'histoire de DevOps a été la publication du livre "Projet Phoenix" par Gene Kim, Kevin Behr et George Spafford. Ce roman raconte l'histoire d'un directeur informatique confronté à une situation désespérée : il a été chargé de sauver un projet de développement de commerce électronique critique qui a mal tourné. Un mentor mystérieux du directeur — un membre du conseil d'administration passionné par les méthodes de production lean — lui révèle de nouvelles manières de penser l'informatique et le développement d'applications, anticipant le concept de DevOps. D'ailleurs, "Projet Phoenix" nous a inspirés à écrire le livre "Adoptez l'externalisation, sinon..." sur une histoire similaire en affaires, où un vice-président des logiciels utilise DevOps lors du développement d'un nouveau produit majeur en externalisation.
DevOps pour l'avenir
Il convient de décrire DevOps plutôt comme un voyage ou peut-être une aspiration, plutôt qu'un point d'arrivée final. DevOps, tout comme la production lean, vise une amélioration continue, une augmentation de la productivité et de l'efficacité, ainsi qu'un déploiement constant. Les outils automatisés pour soutenir DevOps continuent d'évoluer.
Beaucoup a été accompli depuis la création de DevOps au cours de la dernière décennie, et nous nous attendons à voir encore plus en 2018 et dans le futur.
Source : habr.com
