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 .