Rebrand de nom d'équipe en DevOps

#1

Hello,

J’ai besoin d’un peu d’aide pour faire comprendre le devops dans ma boite (comprendre pour mon manager).
Le contexte pourrait être idéal, il en est loin. Il s’agit :

  • d’une PME, environ 30 personnes
  • 10 dans l’équipe technique (il ne reste qu’un ops (moi), 5 dev et ensuite c’est r&d, alternants et d’autres personnes moins tech)
  • migration dans le cloud en 2020. Ca s’est fait un peu dans la douleur, mais dans les temps. Certaines apps ont pu être un peu “cloudisées” mais pas tout. On se retrouve avec des VM bichonnées et un cluster k8s à côté (X2 car 2 environnements).
  • malgré les formations dispensées (formation sur aws (ça s’est pas très bien passé entre l’équipe dev et le formateur, c’est mort dans l’oeuf mais ils ont eu une petite couche quand meme avec un accès pour jouer sur AWS)). On a aussi mis en place une formation sur git/gitlab pour renforcer les points faibles mais là encore, on peut pas dire que ça a été un succès, pour les dev git ça va, mais gitlab, ils y touchent pas
  • y a très peu de motivation à prendre une nouvelle techno (on a une code base assez large, avec déjà pas mal de technos mais ça explique pas tout)
  • organisation en rateau (aucun lead), y a le manager (CTO)

Bref, l’équipe a été rebrandé “Equipe DevOps” et mon manager a fini de me tuer lors d’une réunion sur l’organisation où il a indiqué: “DevOps, c’est le fait faire du Dev puis de l’Ops, DevOps Quoi !”
Je me plains depuis déjà 2 ans d’avoir trop de boulot, de passer beaucoup de temps à faire de la MCO (AWS, y a que moi qui touche, pas par choix, k8s idem, et je gère la trentaine de serveurs avec ansible). Et encore, j’écris les manifests k8s pour les dev… Ca va un peu mieux ces derniers temps mais pendant longtemps je tapais les yum update sur les serveurs (le passe plat). Je m’occupe aussi du monitoring (que je délaisse un peu par manque de temps)…

Bref, dernière chose en date, le dernier dev embauché m’épaule parfois pour des migrations (le fameux devops du coup).

Je leur ai proposé de regarder une présentation de @mcorbin (que j’apprécie bien, tant la vidéo que le personnage, on te voit plus dans le podcast ;)).

Mais je pense faire encore chou blanc, faut cliquer, regarder 45 min de présentation…

J’avais mis en place une doc sous forme de projet gitlab, qui génère un site statique. Y a une CI/CD, faut faire du git et du markdown, c’est pas la mort. Même ça, ça prend pas, je m’occupe de 99.99% des commits. (Et j’ai aps proposé de passer par des merge requests, on commit dans main direct). Je voulais en faire le projet bac à sable, tu le casses, ben c’est pas grave, on prend le temps de le réparer, c’est pas une application pour un client.

Dernier ex, j’ai proposé qu’on teste github copilot. 1 seul dev a été ok. Sur 10 personnes, on est 2 à utiliser.

Bref, je ne suis même pas sûr qu’un accompagnement serait bénéfique. MAis je epux toujours proposer.

Qu’en pensez-vous ?

#2

Hello

Situation pas simple que tu exposes.
D’après tes dires il semble y avoir un problème bien plus profond qu’un simple rebrand d’une équipe de dev en devops.

A la lecture, je me dis qu’il y a un problème de culture et de mentalité dans l’équipe de dev. Ils ont visiblement la possibilité d’utiliser des outils modernes et qui leurs simplifierai la vie mais refusent de le faire. C’est problématique.

Hélas dans ce genre de cas, il n’y a pas 50 solutions :

  • soit c’est imposé par la direction / manager car il y a prise de conscience de la perte d’efficacité (probable) du fonctionnement actuel
  • soit en te faisant des alliers dans l’équipe qui vont aller se faire les relais de tes propositions, démontrer aux autres devs que c’est utile…
  • soit par le renouvellement de l’équipe. Il faut profiter de la fraîcheur des gens (qui vont arriver avec des pratiques qui ne sont pas les vôtres) pour qu’ils fassent passer des messages.

Après dans tous les cas je crains qu’un big bang ne soit pas réalisable, ni souhaitable.

Quelques idées pour essayer de changer petit a petit les mentalités en place :

  • appliquer une nouvelle méthodo sur un nouveau projet
  • mettre en place des communautés de pratiques
  • faire des demo/rex de votre utilisation d’outils (github copilot par exemple)
  • proposer au CTO de lire des rapports type Accelerate ou DevOps state of arts (j’ai plus les noms exacts en tête) ou leurs synthèses pour mettrez en avant les pratiques des autres entreprises et leurs apports

En tout cas, bon courage car faire changer les pratiques quand les personnes y sont réfractaires (d’autant plus si elles se pensent intouchables) c’est très compliqué.

3 « J'aime »
#3

Salut,
nulle part dans ta description de ton enfer :slight_smile: je ne lis “agile”. Ton équipe de DEV fonctionne en SCRUM, en kanban ? En V ? :face_vomiting:
Le fait de travailler en méthodo agile est le premier pas vers le devops et cela va te donner l’opportunité de “rentrer” dans l’équipe et je pense que c’est ça qui te manque, tu me sembles très extérieur à l’équipe.
En plus cela “obligera” à faire du gitflow, des MR, … Je plussois jygastaud, il faut faire ça dans le cadre d’un nouveau projet et surtout il faut un vrai PO qui gère les priorités et les US et donne une direction.
Une question : ta migration vers AWS te coute combien par rapport à ton ancienne infra (on premise a priori). Un ordre de grandeur, j’en ai suivi 2/3 et cela a toujours couté très cher pour des avantages pas à la hauteur, je suis curieux …

P.S. : et avant le burn out, va voir ailleurs …

2 « J'aime »
#4

On est en scrum, sprint de deux semaines. Assez peu d’infos dans les daily qu’on a fini par rendre bi hebdomadaire (c’était censé être au profit d’une autre réu mais ça n’a pas tenu très longtemps :D)
Le PO s’est transformé en 2 POs, un pour la partie très tech, l’autre pour la vision produit.

J’ai des alliés dans l’équipe de DEV mais on a un pilier réfractaire qui sape un peu tout.

J’y travaille un peu mais c’est pas simple. En tout cas, je prospecte depuis un moment, j’ai passé des entretiens sans que ça n’ait abouti (je pourrai faire un autre post à ce sujet, pour un des jobs, j’ai trouvé ça pas top du tout)

#5

Ya pas un pb au niveau du découpage des US ? Une US dans 99% des cas c’est max 2 jours de taf avec un descriptif précis, objectif, résultat attendu, test à faire,… PO c’est un boulot.
Si vous êtes 4-6 à faire le daily il doit y avoir toujours pas mal d’info. Ton lead tech a bouffé ton PO pour les US tech, mais si ton PO tiens toujours le lead sur le projet pas de pb. Tu as des US ? Tu pourrais montrer l’exemple avec celles-ci… Et tu dois en avoir ! Des US tech d’amélioration de la CI, d’intégration de test,…

Pour le taf, soit tu cherches le boulot parfait, soit tu habites le désert, dans les 2 cas tu trouveras pas. :grin:

#6

Les US, parfois, il peut y en avoir. Yep, on est à la ramasse complet…

Je plaide coupable, je suis exigeant et j’habite pas une grande ville… Du coup, je zieute principalement en full remote actuellement.

#7

Beaucoup de choses à dire.

Il y a clairement un manque d’organisation et c’est normalement à votre CTO de prendre les choses en main.

Pour ce qui est de l’organisation de votre équipe et de l’approche DevOps, une ressource assez simple à consulter est : https://web.devopstopologies.com/
Cela met en exergue les topologies d’équipes qui ne fonctionnent pas et celles qui fonctionnent bien.

En ce qui concerne l’usage de git et gitlab, il faut adopter une stratégie de gestion de branche qui serait adaptée à vos besoins. Personnellement, le passage par des PR me semble indispensable, tu peux protéger la branche “main” pour leur forcer la main.

Pour réduire ta charge de travail je pense qu’il faut essayer de standardiser le plus possible vos approches, ça peut passer par :

  • La mise en place de templates CI/CD Gitlab.
  • Standardisation du packaging des app (container).
  • Automatisation de la gestion des VMs (Ansible, Terraform, …).
  • Automatisation de la gestion de l’infra (IaC).

Au début cela va te consommer du temps de mettre ça en place mais cela finira par t’en faire gagner au quotidien.

2 « J'aime »
#8

Sympa ce lien, je vais le partager en interne je pense, Merci

  • template CI/CD c’est en cours, je peine à finir mais la partie technique est faite (pour les conteneurs et k8s, pour le packaging RPM… nop mais c’est pas censé trop durer)
  • packaging en conteneur, ça a été réalisé sur une bonne partie du backend lors de la migration cloud, reste toute la partie frontend et encore certains services backend. En fait, faut tout le temps pousser…
  • Gestion des VMs, j’ai pas mal oeuvré avec ansible, je fais plus de la maintenance mais ca reste assez chronophage
  • Gestion infra, c’est ok aussi, ça me prend peu de temps cette partie