Que contient une «transformation DevOps»?

Certaines sociétés de conseil font la promotion d'un service appelé "Transformation DevOps". Plusieurs grandes entreprises discutent du sujet lors de conférences et de rencontres à travers le monde.

Qu'implique une telle "transformation DevOps"? À quoi cela ressemble-t-il en termes actionnables, à la fois pour les transformations réussies et celles qui ont échoué.

Je dois mettre ma réponse à cette question dans le contexte de ce qu'est DevOps, plus précisément dans les transformations DevOps auxquelles j'ai participé, DevOps est la propriété du cycle de vie complet du développement logiciel. Toutes les pratiques du graphique sont une partie importante de DevOps, et elles permettent et sous-tendent à la fois la pensée systémique et l' amplification des boucles de rétroaction .

Cependant, le principal facteur de différenciation entre CI / CD et DevOps est le fonctionnement réel du logiciel dans un environnement de production, où il peut apporter de la valeur à ses clients et à l'entreprise qu'il sert.

En tant que consultant participant ou dirigeant une transformation DevOps, j'ai les aspects suivants en tête:

• Culture : Comme Dave l'a souligné à juste titre, une culture d'expérimentation continue et d'apprentissage est essentielle au succès de toute transformation. Du point de vue de DevOps, cela se résume à comment engendrer une culture qui soutient le modèle DevOps choisi, ce modèle pourrait être «Vous le construisez, vous l'exécutez» ou il pourrait être plus conforme aux pratiques d' ingénierie de fiabilité de site de Google .

• Modèle opérationnel : il s'agit de la partie de la proposition commerciale qui définit la manière dont l'organisation apportera de la valeur, généralement en articulant les personnes, les processus et les outils utilisés de manière liée à un niveau élevé. Sans modèle opérationnel, vous n'avez pas de modèle pour la façon dont l'organisation adopte les pratiques définies par la culture, ce qui, à son tour, conduit à un manque de clarté et à des comportements divergents.

• C-Level Aircover : C'est souvent notre travail en tant que consultants travaillant dans le cadre de programmes de transformation d'apporter des changements radicaux au fonctionnement de l'entreprise. Vous allez bouleverser les gens et certaines personnes n'aimeront pas les changements - il est important que vous ayez une "couverture d'air" d'en haut pour changer les choses et avancer.

Une fois le niveau élevé en place, il est important de trouver quelque chose que vous pouvez offrir de façon réaliste:

1. Commencez aussi petit que possible, idéalement, une fois que vous avez des gens qui comprennent la culture, une esquisse d'un modèle de fonctionnement et l'adhésion des cadres créent le «projet minimum viable», n'essayez pas de faire bouillir l'océan en introduisant DevOps à un public de milliers. Fixez-vous un objectif réalisable:
   • Automatisez la création de l'infrastructure à partir du produit X.
   • Automatisez la livraison du produit X dans Azure dans tous les environnements.
   • Prise en charge par un sous-traitant Y d'une équipe de développement à Londres.
   • Créez un ensemble de tests autour de notre fonctionnalité la plus risquée et exécutez-les en intégration continue.
2. Très bien, vous avez un certain succès à votre actif maintenant, il est temps de commencer à en faire plus d'équipes, d'ajouter quelques autres équipes dans le mélange et de les mettre en place. N'ayez pas peur d'offrir «White Glove Support» au début pour les aider dans la transition; ils auront besoin de beaucoup de main dans les semaines et les mois à venir.
3. Maintenant, plusieurs adopteurs précoces suivent une nouvelle façon de travailler; vous avez une masse critique, il est temps de commencer à évangéliser le travail que vous faites auprès d'un public plus large:
   • Tenez régulièrement des séances de démonstration et demandez aux premiers adoptants de démontrer à quel point ils ont réussi.
   • Offrez des séances sans rendez-vous pour permettre à d'autres parties de l'organisation d'explorer comment elles peuvent se joindre à votre équipe.
   • Permettre la création de communautés de pratique axées sur des disciplines spécifiques: déploiement continu, tests automatisés, communication commerciale, gestion des risques, surveillance et alertes, etc.

4. Gardez le cap et clôturez la transformation en intégrant le reste de l'organisation. Comprendre la relation entre le cycle de battage publicitaire de Gartner et le cycle de vie d'adoption . Préparez-vous à ce que le programme de transformation tombe dans le «creux de la désillusion», gardez le cap et gardez l'objectif final en vue.

   

Pour une exploration plus approfondie du point final, lisez Crossing the Chasm de Geoffrey A. Moore . Je pourrais littéralement écrire un livre sur la façon de fournir une transformation DevOps, mais au moment où je l'aurais terminée, il n'y aurait probablement plus de travail de transformation DevOps à faire.

DevOps a tendance à se décomposer en trois dimensions principales:

Culture
La culture DevOps met l'accent sur des niveaux élevés de confiance, de collaboration et de communication entre toutes les parties prenantes, en particulier les développeurs, les opérations et la sécurité. La tension et la compétition naturelles entre ces groupes créent des frictions et souvent des dysfonctionnements. DevOps consiste (sans doute) avant tout à aligner les efforts entre ces équipes.

Processus
Les processus de développement DevOps s'alignent étroitement sur les processus Agiles. Les opérations sont encouragées à adopter des pratiques de type Agile pour mieux s'aligner sur les efforts de développement. Les processus alignés sur DevOps sont conçus pour prendre en charge des boucles de rétroaction rapides et rapides tout au long des cycles de vie de développement / livraison. L'intégration continue, la livraison continue et l'amélioration continue (kaizen) sont des domaines prioritaires du processus DevOps.

La technologie
DevOps n'est pas un outil, mais elle est prise en charge par des outils. Il existe des familles entières d'outils prenant en charge une gamme de domaines, notamment l'intégration continue, le contrôle des sources et la gestion du cycle de vie des applications.

Une "transformation DevOps" doit traiter des éléments des trois, mais pas nécessairement tous de la même manière en même temps. Il existe une progression naturelle et un «chemin critique» pour la transformation. L'argument pourrait être avancé, par exemple, DevOps dépend d'une certaine forme de pratique Agile, au moins au sein de l'équipe / des équipes de développement. Il faudra peut-être régler les problèmes de culture avant d'investir dans l'outillage.

Références:
Culture: https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
Technologie: https://xebialabs.com/periodic-table-of-devops-tools/