Happy dev ... & ops

Notes de l'éditeur

1. mais pas que les des
2. Lorsque l’on parle avec les entreprises traditionnelles, on entend parler de dev, testeurs qa, ops, chef de projet Et personne ne se parle Personne n’écoute
3. Un dev ne sait pas si ce qu’il livre va fonctionner
4. Un cp ne sait pas toujours ce qu’il va livrer à son client Et doit faire des claquettes
5. ma petite histoire: dans une ancienne vie, j’ai gagné un jour un centre de services … Broder
6. Et du coup … N’oubliez pas que le client vous a payé et que vous avez signé un contrat … alors dès fois on est prêt à tout pour vendre, après faut assumer
7. C’est fatiguant mais si vous êtes là c’est que vous êtes forcément curieux et intelligents et que vous savez qu’il se passe des choses en dehors des murs de votre entreprise Aujourd’hui (alors je suis en plein dans l’IT, c’est mon métier), je fais un constat:
8. Avant c’était les SSII, les éditeurs, … Les entreprises évoluent -> de consommatrices de logiciels, elles deviennent créatrices de données et de logiciels (qu’elles monnayent d’une manière ou d’une autre) et leurs exigences en termes de recrutement changent aussi Si les entreprises ne prennent pas se tournant, elles seront vite hors jeux donner des exemples d’entreprises: Uber, Netflix, … ou les utiliser plus loin
9. btw, le futur, c’est maintenant Depuis une bonne dizaine d’année, l’open source est source d’innovations et génératrice des bases de l’IT actuelle (Linux, Java, Go, PostGreSQL, …) et en plus ces bases sont maintenues par les communautés Des pratique issues de l’oss permettent de construire plus vite, de répondre aux problématiques de sécurité, et de fournir de meilleurs et plus robustes produits
10. Por cela, De plus en plus d’entreprise adoptent pour elles mêmes (en interne) ces méthodes de développement issue de l’opensource pour construire leurs propres logiciels. On parlera d’inner source
11. Les équipes doivent se parler et partager les informations Transparence: comment est construit le code, pourquoi les décisions sont prises, … (donner l’exemple de GitHub ou Clever, comment ils bossent) -> Gestion de conf, doc, issues, slack … Communauté et mentorat: esprit d’équipe, partage par les sachants qui font monter en compétences Prototypage rapide: principe du Lean - Minimal viable product -> avoir la possibilité de se tromper facilement et de recommencer = moteur d’innovation On trouve ces qualités dans l’oss et elles sont de plus en plus adoptées par les entreprises privées
12. Le code est largement partagé et expliqué (pas limité à une équipe) Favoriser le re-use, mais aussi la recherche/veille technologique Toute personne, quel que soit son niveau, son métier, … doit pouvoir contribuer et donner son avis - et cela aidée par l’outillage adéquat Les workflows doivent être simples et fluides (exemple du GitHub Flow, mais aussi du Clever Flow) Les contributions sont jugées pour leur valeur et non par le “grade” du contributeur Toutes les discussions sont publiques et traçées et indexées -> la vie et la recette du projet
13. C'est de ce type de valeurs qu’ont émergées des mouvances dont la finalité et d’améliorer le travail de tous
14. C'est avant tout une philosophie, destinée à améliorer la production de l’entreprise amélioration de l’expérience client Accroissement de la capacité à innover Accélération de la production de la valeur
15. Les 4 principaux sont les suivants
16. développement et tests sur des systèmes similaires à ceux de la prod Permettre aux équipes très rapidement de developper et tester “comme en vrai”
17. Déploiement avec des processus réutilisables et fiables L'automatisation est essentielle pour créer des processus itératifs, fréquents et fiables Cela donne à l’équipe la possibilité de tester les processus de déploiement eux même et réduire les risques d’échec
18. Surveillance et validation de la qualité opérationnelle Lorsqu’une application est déployée et testée, des mesures de qualité doivent être capturées et analysées. La surveillance fréquente permet d’être alerté en amont des problèmes opérationnels et de qualité qui peuvent apparaître dans l’environnement de production.
19. Amplification de la boucle de retour L’un des objectifs de DevOps est de permettre aux organisations de réagir et de procéder aux modifications plus rapidement.
20. C’est ça qui va faciliter l’innovation avoir la possibilité d’échouer facilement l’innovation c’est une suite d’échecs et de tests jusqu’a ce que le succès arrive mais pour réussir il faut accepter l’échec et vous devez vous créer votre espace de jeu dans lequel vous allez pouvoir vous planter
21. permettre d’oser sans tout casser
22. ce n’est pas qu’un outillage, ce sont des processus de travail itérer: ajouter le bout de code qui va bien pour améliorer une feature (système de feature branch) c’est valable pour le code application mais aussi pour les codes d’automatisation de la chaine échanger, avoir des conversations, comprendre, tracer, laisser les recettes - capitaliser regarder ce que font les autres - ne pas réinventer la roue, faire des revues de code lancer / déployer -> surveiller, capturer les résultats, mais aussi les réactions, capitaliser
23. Tout le long donner des exemples d’outils (GitLab, Markdown, Jenkins, …) Git of course Il ya généralement beaucoup plus d’outils dans une chaine devops, la on simplifie
24. faire une parenthèse sur le déploiement Provisionning de VM etc … TODO faire un slide Devops CLOUD
25. il faut une équipe
26. Devops, ce n’est pas faire des économies et tout faire faire au dev c’est bien d’avoir une culture commune, de comprendre ce que fait l’autre voir le backuper (les vacances c’est important) Mais on reste une équipe et on se forme les uns les autres (mentorat)
27. Un seul ops ne peut pas tout faire l’automatisation n’est pas là pour diminuer l’équipe elle est là pour améliorer tout ce qui est répétitif et donc diminuer les erreurs / les risques
28. Ok, on a tout automatisé le CP comprend les process, les maîtrise, voire même en urgence il va provisionner des machines/VM voire même il va re déployer mais le gars il est là pour gérer, faire attention aux deadlines, aux coûts, … Donc laisser le faire son boulot sereinement, un CP pas stressé c’est le meilleur chien de garde de l’équipe
29. ce n’est pas compliqué donner des exemples le meilleur, c’est mieux que le bon à vouloir faire cheap pour économiser un peu, à la fin ça cassera Ex GHE, quand tu sais que ton outil est stable et que tu n’a pas à le maintenir, tu as payé un prix, mais tu gagnes du temps, de la sérénité, … de l’argent
30. donner des exemples Il y a l’exemple du GitHub Flow, mais on pourrait se faire un délire sur le CleverFlow + BlueGreen deployment un truc en 5 étapes choose your runtime choose your project size your instance setup deploy - ignition - that’s all - < 5 minutes, 30 seconds if you’re good
31. on oublie le CP, le QA, les testeurs
32. des idées intelligentes de fix d’améliorations de nouvelles features la team devient force de proposition
33. voire vous allez obtenir de nouvelles pratiques