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

source :  http://shop.oreilly.com/product/0636920039846.do

If we take a look at the book (a great book in my opinion) the The Four Pillars of Effective Devops we have :

  1. Collaboration
  2. Affinity
  3. Tools
  4. 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 .

source :  https://mindmajix.com/agile-vs-devops

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 .