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:
- 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.
- 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.
- 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.
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.
