Evaluer DevOps… CALMS offre un cadre de référence pour évaluer et comparer la maturité d’une équipe DevOps et son état face aux changements transformationnels qui l’accompagnent.
Qu’elle cherche à déployer une structure DevOps ou à apporter des améliorations à un déploiement existant, les entreprises ont besoin d’analyser la maturité de leurs équipes – IT développement, Infosec, métier, QA - comme de leur processus automatisés sur DevOps. Car leur objectif est moins de savoir utiliser une technologie que de rendre les opérations plus agiles et plus réactives aux besoins de clients.
C’es pourquoi en couvrant toutes les parties prenantes dans DevOps, le modèle CALMS (Collaboration, Automation, Lean, Measurement & Sharing) est un cadre de référence qui se révèle utile pour analyser la structure DevOps, et cela dans n’importe quelle organisation.
Culture
Comment défendre le ROI (retour sur investissement) prévu lié à l’automatisation d’un processus au sein de l’équipe DevOps ? Pour qu’un projet aboutisse, il doit bénéficier de l’appui des dirigeants de l’entreprise. C’est la partie cruciale de la ‘culture’, afin de ne pas investir dans la technologie opiur la technologie, mais pour répondre à un besoin commercial.
Automatisation
Si l’objectif de l’entreprise est de déployer et mettre à jour les applications et le code ‘très’ vite, le risque est que ce déploiement aille ‘trop’ vite. L’automatisation est destinée à prendre cela en charge et à compenser. Mais attention, tout le monde ne peut pas le faire…
Lean
Dans le cadre de CALMS, la composante Lean est relativement sim^ple à évaluer, puisqu’elle repose sur la documentation des économies de coûts et l’élimination des ressources. Mais attention, à trop chercher à être Lean, le risque est de se tromper sur l’assurance qualité.
Mesure
S’il est relativement facile de mesurer le succès d’un déploiement logiciel une fois celui-ci terminé, c’est beaucoup plus difficile d’essayer de le mesurer dans le cadre d’un modèle de précision pour le futur. Les mesures devraient permettre de localiser rapidement les erreurs au cours du post-déploiement afin de corriger le code si nécessaire également très rapidement
Sharing (partage)
Si DevOps signe la fin du développeur solitaire, le piège est de continuer son propre travail sans penser suffisamment à l’équipe. C’est pourquoi le partage doit chevaucher la culture afin que les équipes travaillent ensemble et que la communication soit une réalité.
Image d’entête 833107270 @ iStock monkik
