J’adore l’envoûtement derrière le devops . A la base c’est partie d’un principe simple et louable qui est de mettre les devs et les ops autour d’objectif commun afin d’avoir un meilleurs TTM .
« Powah , C’est Top » , est le premier ressentie que j’ai eu quand je me suis intéressé au sujet et fait le tour de certaine lecture .
Mais au delà du buzz word et dans les faits , c’est un autre monde .
Lors de divers intervention , discussion avec des collègues et Ă©change pendant des Meetups , le sujet m’interpelle souvent . Beaucoup de rapprochement est fait entre le Tooling nĂ©cessaire a une bonne mise en place de la culture Devops , et le Devops en lui meme et mĂŞme pire le Devops et rapprochĂ© au CI/CD !
1- Devops is not about Tools
If we take a look at the book (a great book in my opinion) the The Four Pillars of Effective Devops we have :
- Collaboration
- Affinity
- Tools
- Scaling
Tools is only a one from 4 pillars . So please Devops it’s more than Tools
2 - We need to Hire a Devops
Autre chose que je remarque souvent dans la transformation de certaine entreprise , c’est le fameux « Weed need to Hire a Devops »
Et la encore je saigne des oreilles …. et la c’est plus un souci de naming . Devops is a culture , Devops is a way for building software ; we can’t hire an engineer for doing this without a change in a howl delivery process .
There is no magic engineer called Devops , qui en plus a la lourde tâche de faire de l’automatisation , du CI/CD , de la perf en continue, l’automatisation , les Devs etc…. Bref a Hero .
Le Devops est une transformation de l’entreprise @Scale un cran au dessus de l’agile à mon sens .
Cela commence par créer des Feature Team capable d’apporter de la valeurs en toute autonomie jusqu’à comment les ops sont chiffrer pour les projets .
Si les ops sont dans une enveloppe budgĂ©taire et les devs dans une autre , alors il y’a toujours un problème d’oĂą le @Scale . Il m’ait arrivĂ© durant mon experience de voir une squad sans Ops sous prĂ©texte que ce dernier n’a pas de budget …. Dommage d’en arriver la surtout quand l’ops est au bench 🙂 .
Dev VS Ops deux monde appart :
Le Devops a aussi beaucoup bousculĂ© les ops qui dans leur nature sont Ă la recherche de stabilitĂ© de garder dans leur SI des choses qu’il maĂ®trisent au mieux , contrairement au Dev qui cherche Ă livrer de plus en plus vite , Ă ajouter des nouveau composant permettant de rĂ©pondre Ă certaine problĂ©matique mĂ©tier . Du coup Ops dans une dĂ©marche Devops se retrouve a devoir suivre le rythme imposĂ© par les besoins mĂ©tier poussĂ© par les Devs . Et cette dynamique a crĂ©er , dans mon entourage en tout cas , des ops dit rigide n’aiment pas forcĂ©ment sortir de leur zone de maĂ®trise et d’autre plus souple aiment scriptĂ© , automatiser , voir mer dĂ©velopper . Vous voulez savoir si votre Squad est sur bon chemin du Devops ? Regarder combien de membre de la squad font un git push ! C’est automatique Ă mon sens , tout se doit d’être versionĂ© , source mĂ©tier , source Ansible, Terraform , Gatling , … etc
Et puis il y’a le DevSecOps , SecDevOps , DevOpsSec la communauté n’a pas encore tranché ! Mais ça c un autre sujet .