DevOps = Dev. to Prod. ?
DevOps = Dev. to Prod. ?

DevOps = Dev. to Prod. ?

Cela fait quelques temps que je pense écrire cet article car il m’est arrivé d’entendre à maintes reprises, le DevOps c’est laisser les Dev. pousser jusqu’en Production. Et bien OUI et NON car c’est un raccourci qui réduit un peu trop la réalité. Je ne décrierai pas ici tous les fondements du DevOps, mais quelques lignes pour pondérer ce postulat trop régulièrement érigé au rang d’axiome.

L’un des piliers fondateurs du DevOps repose sur les modalités de déploiement du code d’un environnement à l’autre. Résumé par l’acronyme CI/CD on y associe de temps à autre un principe d’autonomie libertaire. Cette tentation est argumentée par un motif sous jacent visant à réduire au maximum les contraintes de mise en Production.

Avant d’aller plus avant, considérons un autre acronyme : SoD pour — Segregation of Duties * — (ici in DevOps teams). Le concept est somme toute assez simple, il vise à répartir les responsabilités et les actions associées dans les mains de plusieurs acteurs; l’objectif étant de réduire les risques (fraudes et erreurs) lors de passage en Production notamment.

Confronter SoD au dynamisme du DevOps et nous voilà en pleine contradiction car le fonctionnement DevOps nécessite l’autonomie de l’équipe afin de garder les bénéfices de rapidité et d’agilité. Pour cela elle doit pouvoir compter sur la confiance de son entourage et être libre de faire ce qu’elle entend au moment où elle le souhaite. Mais :

“avec de grands pouvoirs viennent de grandes responsabilités” *

Ainsi il n’est pas acquis de facto de laisser libre droit à l’équipe DevOps de livrer toute seule son lot en Production… En effet, les “vieux” concepts, issus d’ITIL généralement, occupent toujours les organisations et les habitudes. Nous pourrions passer des pages à converser sur le bien fondé de ces “anciennes” pratiques face à la déferlante de nouvelles du 21ème siècle que nous ne ferions rien avancer. Le sujet est donc,

1/ de considérer que le SoD — Segregation of Duties in DevOps teams — est une réalité et qu’il faut faire avec;

2/ s’interroger sur les modalités à mettre en œuvre pour limiter l’impact de ce découpage de responsabilités (qui in fine tente de réduire le risque de perturbation tout en rassurant beaucoup de monde…) et donc progressivement pivoter les pratiques actuelles vers plus de “DevOps”.

Observons le cheminement du code depuis sa création jusqu’à son utilisation en Production :

image

Source ici

Premier constat, la réduction du SoD n’est envisageable sérieusement qu’à partir du second cas (Continous Delivery) et idéalement dans le cas du Continous Deployment. En effet, nous allons rechercher un mode opératoire sécurisé par une automatisation poussée (ainsi que des tests automatisés eux aussi…). Automatisation ne veut pas dire sans contrôle et la dernière étape peut alors se matérialiser par une validation humaine/process qui engagera la finalisation du process automatisé.

Mettre en œuvre une chaîne complète de déploiement (Continuous Delivery ou mieux Continuous Deployment) est une cible qui nécessite de l’effort ! Donc du temps et une maîtrise technologique pointue. Idéalement il faudra mettre en place ces 3 éléments :

1- Une automatisation robuste

2- Un mécanisme de déploiement intelligent, blue/green, etc.

3- Un monitoring vif

Alors pousser son code jusqu’en Prod. en un minimum d’interventions est bien possible, souhaitable et profondément DevOps, mais cela ne se décrète pas !

De conclure que tout ceci peut se mettre en musique si l’environnement technique est propice. Sur ce point, j’ai une profonde conviction pour le Cloud Public, mais là je suis parti pris ;)

PS : les 3 items ci-dessus : Automatisation / Déploiement / Monitoring feront l’objets de futurs articles…

Merci pour votre lecture. Si cet article vous a plu, merci de le partager sur vos réseaux 😉

Jean-Pierre Chamarande - Jan 09, 2019

image