Un chemin pratique vers la maturité DevOps

Toute méthodologie agile est vaine sans de vraies pratiques DevOps. Le mot à la mode a été mal utilisé dans de nombreuses organisations. Si vous dites que vous avez des équipes agiles mûries et que vous avez un ingénieur DevOps ou une équipe DevOps, qui ne vont probablement pas dans la bonne direction. DevOps est une culture plutôt qu’un nom ou une désignation d’équipe. S’inspirant du CMM (Modèle de maturité des capacités), cette tentative vise à aider une organisation à savoir où elle en est dans un parcours DevOps et comment avancer. Avec un brainstorm entre les équipes de développement et d’opérations, cela peut être élargi et personnalisé en fonction des besoins de l’organisation.

Aucun nombre n’est mauvais car il aide un individu ou une organisation à se développer.

Client satisfait

Contrairement à CMM, ce n’est pas un modèle que vous devez prouver à un organisme de certification. Le seul certificat que vous obtenez provient de vos clients satisfaits ou de vos partenaires commerciaux. C’est un modèle pour réfléchir et aider les entreprises à se développer. Le but même de toute équipe informatique est de créer de la valeur en assurant une livraison durable et prévisible avec qualité.

Il s’agit d’un modèle simple qui, du développeur au CxO, peut comprendre et relier.

Avant de discuter du modèle. Nous devons comprendre le besoin de ce modèle. Il y a de nombreuses années, Melvin Conway dans son article « Comment les comités inventent-ils? »est venu avec une thèse qui est devenue célèbre sous le nom de loi de Conway.

Toute organisation qui conçoit un système (défini au sens large) produira un design dont la structure est une copie de la structure de communication de l’organisation.

La loi est basée sur le raisonnement selon lequel pour que les modules logiciels fonctionnent, plusieurs personnes doivent communiquer fréquemment entre elles. Par conséquent, la structure de l’interface logicielle d’un système reflétera les limites sociales de la ou des organisations qui l’ont produit, à travers lesquelles la communication est plus difficile.

Regardons comment cela fonctionne dans le développement de logiciels avec un scénario réel. Radha construit un écran frontal qui affiche les attributs détaillés d’un produit. Dites que ce produit est un téléphone portable. Peu de détails communs sur les produits sont la couleur, le prix, les dimensions, les notes, etc. Un nouveau règlement est venu pour afficher la valeur SAR du combiné. L’écran qu’elle a conçu fonctionne avec micro service call. Elle a parlé à Sunil qui travaille dans l’équipe de données. Il a dit qu’ils ne pouvaient envoyer des données qu’en fichier plat. Il y a une déconnexion claire entre deux modules. C’est un scénario que chaque équipe informatique rencontre, sinon tous les 100%, mais la majorité des fois. C’est juste un problème de conception. Le problème est plus large. Et si les priorités de l’autre équipe sont très différentes de ce que fait votre équipe? Vos besoins peuvent être la priorité la plus basse pour eux pendant que vos parties prenantes courent derrière vous.

La première étape vers une implémentation DevOps réussie est d’être ouvert aux changements d’organisation.

Changements d’organisation

Permettez-moi de discuter de 5 niveaux de maturité:

  1. Initial: Dans cette phase, les équipes travaillent en silos et il n’y a qu’une collaboration basée sur les besoins. Lors d’une réunion avec toutes les équipes ensemble, si vous demandez à qui appartient le « Produit », vous n’aurez aucune main levée. Le délai de mise sur le marché est généralement plus long, allant jusqu’à des mois et parfois des années. Les priorités sont définies au niveau de l’équipe, mais pas au niveau du produit. Cela conduira chaque équipe à avoir ses propres priorités. Comme il n’y a pas de processus défini, chaque tentative revient à réinventer la roue. Cela entraînera des problèmes de qualité et des délais plus longs. L’équipe effectue principalement des déploiements manuels et des interventions manuelles. Bien.. ce n’est pas un mauvais état. C’est ainsi que la majeure partie du développement commencerait.

2. Reproductible : Les équipes travaillent toujours en silos. Il y a un certain niveau d’automatisation au sein de l’équipe. Lorsqu’une crise survient, l’équipe définit son propre processus et le suit jusqu’à la fin de la crise. Seule bonne nouvelle, certains d’entre eux peuvent devenir des processus répétables lorsque la crise recommence.

3. Défini : C’est un bon point de départ pour semer la culture DevOps avec une équipe centralisée. Cette équipe comprend les différentes technologies utilisées par les équipes de développement et l’outillage est basé sur les besoins actuels. Étant une équipe centralisée, il n’est pas facile de surveiller ce que chaque équipe fait et certaines décisions sont donc laissées aux équipes pour expérimenter. L’équipe centrale se compose généralement d’experts et les équipes de développement auront des personnes ayant une compréhension et des connaissances de base.

4. Géré : Alors que l’équipe DevOps centrale comprend le paysage de l’outillage de l’organisation, plusieurs environnements et outils sont testés. Des processus cohérents et reproductibles sont suivis par plusieurs équipes. La chaîne d’outils est sélectionnée en fonction de cas d’utilisation plutôt que de choix personnels. Des outils de suivi de tous les processus sont introduits et largement utilisés par les équipes pour prendre des décisions.

5. Optimiser:

Le succès d’un bon leader se définit par le fait de ne pas avoir d’adeptes, mais par la capacité de créer de grands leaders.

La dernière étape de la maturité DevOps consiste à faire disparaître l’équipe DevOps. Cela pourrait sembler contre-intuitif. À ce stade, DevOps fait partie de l’équipe de développement de produits plutôt que d’une entité distincte. Utiliser l’infrastructure comme code, conteneurs, orchestration, etc. le déploiement sans contact est atteint. Maintenant, si vous appelez tous ceux qui travaillent sur un produit et demandez à qui appartient le produit, vous aurez des mains confiantes qui se lèvent sans aucune hésitation. Les données des outils de surveillance sont utilisées pour sélectionner un nouvel ensemble d’outils (y compris l’infrastructure, les langages de programmation, les techniques). Les décisions sont basées sur des données plutôt que sur des préférences personnelles. L’équipe produit est prête à déployer du code n’importe quand et n’importe quand. Ils aiment la « valeur commerciale » et la traitent comme un animal de compagnie. Tout le reste est traité comme du bétail.

Modèle de Maturité DevOps.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.