Certes, il y a deux ans, j'étais l'un des principaux contributeurs au bruit autour de DevOps, avec des conversations ancrées dans le mouvement autour de la culture, des principes et des objectifs. Et bien que tous ces éléments des environnements DevOps soient importants, j'ai constaté que le plus grand défi aujourd'hui est le manque de compréhension des raisons pour lesquelles DevOps est bénéfique. Il s'agit de faire bouger les choses ou simplement de passer à l'étape suivante. La meilleure façon de commencer sur la voie du changement est de jeter un œil aux entreprises qui ont déjà fait de grands progrès dans la livraison de logiciels modernes. Il n'existe pas de DevOps unique, mais il existe des implémentations existantes qui contiennent un trésor de conseils et d'astuces, et parfois même des stratégies d'implémentation directe pour DevOps robuste .

Voici six implémentations DevOps qui, selon moi, se concentraient sur la transformation des méthodes en résultats (avec des présentations de chaque entreprise de la liste) :

Docusign

Le développement de Docusign a toujours été agile. Mais passer à l’étape suivante, vers les processus DevOps, n’a pas été si simple. En raison de la nature de leur activité (contrats et signatures), des éléments tels que l’intégration continue et la livraison constituent sans aucun doute un sérieux défi. Ils vivent et meurent par les transactions, pas celles de l’argent, mais par l’échange de signatures et d’approbations. Si quelque chose devait mal se passer et qu’une approbation était attribuée de manière erronée, par exemple, cela constituerait un problème sérieux. Ainsi, pour soutenir la vitesse de développement moderne, ils utilisent un outil très intéressant appelé application mock (dans ce cas, une simulation pour leur API interne). L’outil propose un point de terminaison fictif et fournit des réponses fictives. Ils sont capables de combiner cela avec la gestion des incidents et, avant la publication, de tester l’application avec des simulations très proches des échanges réels. Voir Slideshare »

Fort

Tout comme Docusign, l'application de Forter dépend des transactions rapides et sensibles. Forter met l'accent sur l'auto-réparation des problèmes grâce à une gestion rigoureuse des incidents. Ils ont construit une architecture agréable pour gérer tous les problèmes. Ils ont un processus de filtrage pour identifier les problèmes courants afin de tenter de les résoudre automatiquement, ou pour référence ultérieure afin de les traiter et de les intégrer dans leur système. Cette concentration non seulement sur la résolution des problèmes, mais aussi sur leur prévention à l'avenir est ce qui leur permettra de faire progresser leur chaîne de distribution. Voir Slideshare »

Turnitine

Turnitin est une plateforme qui permet aux étudiants d'améliorer leur écriture. (J'aurais pu m'en servir pendant mes études.) J'ai beaucoup appris de Samantha, responsable de base de données chez Turnitin, lors de sa présentation sur la manière dont la surveillance est utilisée pour améliorer les performances de la base de données dans leur application. Je ne suis pas DBA, mais être capable d'identifier les pics normaux et anormaux, de surveiller le temps de réponse du backend et de réagir aux pics anormaux le plus rapidement possible est important pour toute application. Voir Slideshare »

Gengo

Gengo est une plateforme de traduction. Elle est utilisée à la fois par les utilisateurs finaux commerciaux et par les développeurs pour l'intégration dans leur application. Ils ont un point de vue similaire à celui de Forter où ils ont choisi la surveillance intelligente comme voie, non seulement pour de meilleures applications de production, mais aussi pour des objectifs plus vastes tels que libérer du temps au sein de l'équipe pour innover. En particulier, en raison de la nature distribuée de leur API, les problèmes détectés à la suite d'une mise à jour peuvent être particulièrement difficiles à repérer. Voir Slideshare »

Ce que j’apprécie vraiment dans les quatre implémentations ci-dessus, c’est qu’elles ne sont pas les licornes DevOps, et elles ne sont pas les enfants modèles de DevOps (comme Netflix ou Etsy), ce qui rend leurs histoires plus pertinentes pour toutes les applications.

Mais regardons aussi les deux enfants de l'affiche :

Etsy

Etsy est un praticien hautement référencé de DevOps, ainsi qu'un contributeur à la technologie et outils disponibles dans l'espace. Elles révèlent une approche descendante de l'adoption de DevOps. L'ensemble de l'organisation a compris très tôt que le changement à long terme devrait se concentrer sur la culture, les approches de recrutement, les techniques de motivation, etc. Mais du côté tactique (infrastructure), ils se sont concentrés sur la pollinisation croisée des équipes, une politique de porte ouverte et une visibilité pour tous. Voir Slideshare »

Netflix

Plus encore qu'Etsy, Netflix est présenté comme le rêve DevOps. Et les exemples ne manquent pas pour démontrer comment leur environnement fonctionne à plein régime (et toutes les choses cool qu'ils font). Dans leur présentation, faites attention aux architectures de référence et à la façon dont ils s'assurent que leur base de données Cassandra ne tombe pas en panne. Boom! Ils consacrent beaucoup d'efforts aux tests complets des bases de données pendant le processus de publication. Souvent, les backends ne sont testés qu'après plusieurs versions et dans des scénarios limités. Voir Slideshare »

Trouvez votre propre manuel de jeu

Il est courant de trouver une implémentation qui correspond à la vôtre, et cela peut servir de manuel étape par étape pour la mise en œuvre de DevOps dans votre propre organisation. Cependant, en raison des variations entre les piles, les applications et les équipes, la duplication du processus d'une autre organisation n'est pas possible. Pourtant, il y a beaucoup à apprendre de ceux qui revendiquent des victoires dans leurs pratiques DevOps, et il est possible de s'appuyer sur ce qu'ils ont appris.