Je fais suite à cette remarque du chef de ce forum en ouvrant ce sujet.
Je ne pense pas faire dans l’originalité sur ce sujet, mais voici ce que nous faisons dans l’entreprise sur l’agence Grenobloise.
Premièrement nous avons des communautés sur des sujets techniques, Java, dot net, web, db, … et bien sur DevOps.
J’essaye d’animer cette communauté, on se réunit en 12/14h une fois pas mois pour présenter, échanger sur un sujet.
Je le signale parce que c’est quand même important, comme c’est lors de la pause de midi, l’entreprise participe en nous payant le déjeuné et nous met à disposition une bonne salle. Les animateurs ont aussi la possibilité de mettre des heures pour la préparation de ces animations techniques.
Ces animations sont ouvertes à tous et aussi à des extérieurs même si pour le moment on a pas communiqué sur le sujet. On devait le faire plus cette année, mais bon Covid a ruiné pas mal de nos plans . L’autre ambition, c’est pour certaines sessions de les jouer en webinar, afin de partager plus largement dans notre business unit et en France.
Par ailleurs j’ai un meetup sur le Floss, et dans ce cadre, j’essaye de faire ces meetups dans l’entreprise pour faciliter l’accès aux personnes qui seraient intéressées par le sujet et créer des ponts.
Voilà à titre indicatif les sessions que l’on a faites sur 2018/2019 :
-
Juin 2018 : Lab docker 101 première partie (engine) à https://github.com/uggla/Labs/blob/master/Docker/README.md
-
Juillet 2018 : session vidéo estival.
DevOps explication : https://www.youtube.com/watch?v=M6F6GWcGxLQ&list=FLrHVlMrSKUE7jJAt34kAu_w&index=5&t=184s
Une présentation sur Ansible : https://www.youtube.com/watch?v=kaaYboumlw8&list=FLrHVlMrSKUE7jJAt34kAu_w&index=4&t=1227s -
Septembre 2018 : Lab docker 101 #2 (docker-compose + swarm) à https://github.com/uggla/Labs/blob/master/Docker/README.md
-
Octobre 2018 : Dompter le pinguin
L’objectif de cette session et de configurer votre station de travail pour être plus efficace sur ces technologies.
Trucs, astuces, bonnes pratiques d’installation et de configuration des outils comme ssh, bash, putty, cygwin etc…. -
Novembre 2018 : Construite votre intégration continue avec Docker
Présentation rapide 20/30mn puis lab de 1h30 visant à mettre en place une intégration continue avec les outils (github, jenkins, sonar) pour un projet hello world -
Décembre 2018 : Pas de session cause préparation Flosscon.
-
Janvier 2019 : Flosscon mini conférence sur le Floss 3j dont un jour dans l’entreprise.
Les présentations sont attachées aux sessions ici (tout n’est pas disponible) : https://flosscon.org/conferences/FLOSSCon2019/schedule -
Février 2019 : Un retour d’expérience sur le DevOps chez un gros client.
-
Mars 2019 : Vim and tmux survival kit for Dev (answer stackoverflow most requested question) + Meetup Rust #1
-
Avril 2019 : Infra as code #1: Terraform
-
Mai 2019 : Infra as code #2: Ansible + Meetup Rust #2
-
Juin 2019 : Bash is not a second zone citizen programming language.
-
Juillet 2019 : Comme c’est les vacances, meetup sur comment jouer mais sous Linux.
Dans l’entreprise, c’est majoritairement des profils de développeurs, donc les présentations sont plutôt formatés en ce sens.
Avec le temps, j’essaye aussi de donner plus des trucs qui peuvent les aider au quotidien.
Petite anecdote, le sujet de Mars 2019 c’est parce qu’un petit jeune m’a fait de la peine à ouvrir Atom, faire des copier/coller et des copies de fichier pour éditer un pauvre fichier de conf de 5 lignes. Je me suis dit qu’avec quelques rudiments de vim, il aurait pu modifier son fichier avant qu’Atom soit chargé.
Aussi j’adapte les sujets des sessions en fonction de mon temps vs mes projets clients.
Maintenant pour la formation des membres de l’équipe virtuelle DevOps.
Honnêtement, je connais pas vraiment d’autre moyen que de passer du temps, voir beaucoup de temps.
Donc basiquement, j’essaye de faire une espèce de pair programming sur ce que la personne doit faire afin de l’accompagner. En essayant de suivre les points, conditions suivantes (liste pas forcement ordonnée).
-
Selon moi, la condition sine qua non c’est que la personne soit en poste et confronté à la réalité et à des vrais problèmes.
-
Je suis entièrement d’accord avec ce qui a été dit sur radio DevOps, il faut blinder les fondamentaux. (OS (Linux what else ? ), man, bash, ssh, réseaux, culture informatique, bonne pratique de dev, docker, tests…). Plus les bases sont solides, plus c’est facile de s’adapter à d’autres technologies. Sachant que dans notre domaine, c’est impossible de tout connaître.
-
Essayer de donner des pointeurs vers des bonnes sources de documentation.
-
Essayer de donner du contexte. On peut être champion sur une techno, mais si on sait pas pourquoi et comment elle est utilisée par le client.
-
Essayer pour les nouveaux de passer du temps à les aider au setup de leur poste de travail (vpn, proxy, outils, etc…). Autant de chose propre à chaque structure/client.
Pour les outils, ne rien imposer, essayer de s’adapter à ce que la personne connaît. Voir montrer des alternatives. -
Essayer de travailler sur des choses qui vont vraiment être utilisés. Exemple, j’ai donné à quelqu’un la réalisation d’un script python pour valider un certains nombres de critères sur un fichier de configuration. Comme ce script aller être utilisé en vrai dans la CI de prod du client, hors de question de faire l’impasse sur les TU par exemple.
-
Essayer d’écouter. Faire des checkpoints. Demander si ça va et ce qui ne va pas. Ça peut ne pas passer autant le savoir. Attention à mettre les personnes dans une position favorable pour le faire, car c’est pas toujours facile pour quelqu’un de nouveau de critiquer son « formateur ».
-
Le plus difficile, essayer de prendre du temps. Souvent je me déteste quand on est pressé, car je deviens trop dirigiste. Essayer de plus laisser faire, partir faire un autre truc, et revenir plus tard pour aider, débloquer. Faire réfléchir, pas forcement donner la réponse, mais faire en sorte que la personne se pose des questions.
Le problème de cette méthode c’est que ce n’est pas un mode de fonctionnement qui passe à l’échelle.
Je vais essayer de solliciter un ancien collègue qui travaille sur des formations à plus large échelle, de venir nous en parler un peu.
Et vous comment faites-vous ?