Une transformation DevOps
En tant qu’ingénieur DevOps, j’aimerais partager une des expériences que j’ai rencontrées au cours de ma carrière, lorsque j’ai découvert une organisation très silotée. A travers ce témoignage nous allons aborder :
Qu’est-ce que le DevOps ?
Le DevOps est un changement culturel visant à combler le fossé/décalage entre les équipes. Nous appelons également ce fossé/décalage, le mur de la confusion. Lorsque les équipes sont séparées par un système de suivi des problèmes et rejettent le travail à l’équipe suivante. Cette situation crée :
- un manque de visibilité de bout en bout
- peu de feedback
- peu d’apprentissages possibles
Ce mur de confusion est à l’opposé des Three ways : Les principes qui sous-tendent DevOps. Certaines conséquences sont :
- un faible engagement des employés,
- une faible capacité à délivrer de la valeur au client,
- la création de complexité organisationnelle.
Que fait un ingénieur DevOps ?
Dans mon département, nous avions plusieurs équipes de développement. En outre, nous avions une équipe DevOps chargée de soutenir la livraison du code au département qui gère l’infrastructure sur site. Mon équipe avait déjà mis en place un pipeline CI/CD qui lui a permis de réduire le temps de déploiement d’un week-end à 40 minutes. Malgré cette réussite, les choses restaient confuses du point de vue DevOps.
Par exemple, après mon onboarding, j’ai reçu mon premier ticket dans notre help desk. On m’a demandé de créer un dépôt (de code) git. J’ai donc commencé à poser des questions sur le flux de travail, la stratégie de branchement, etc. Mais on m’a gentiment conseillé de dupliquer le modèle. J’étais perplexe car lors de mon expérience précédente en tant que développeur, la gestion du dépôt de code faisait partie de mon travail. Quelques minutes plus tard, j’ai reçu un autre ticket pour créer un pipeline de construction. J’ai alors commencé à poser des questions sur le SDK, la stratégie de test, les exigences de déploiement, etc. Mais on m’a une nouvelle fois conseillé de dupliquer à nouveau le modèle. Après ces événements, je me suis demandé « pourquoi ils avaient engagé un ingénieur DevOps pour dupliquer les modèles ? »
Comment faire du DevOps lorsque l’entreprise n’en fait pas ?
Pour commencer à contribuer à une organisation plus DevOps et améliorer la livraison de logiciels, nous avons identifié trois priorités clés :
- Premièrement, responsabiliser les équipes de développement.
Pour relever ce défi, nous avons commencé par nous positionner comme un facilitateur, en nous efforçant de réduire notre implication dans le processus de livraison. Par exemple, nous ne créons plus de dépôts de code ou de pipelines CI/CD. Au lieu de cela, nous assurons la gouvernance, la formation et l’accompagnement, afin que les développeurs soient en mesure d’utiliser ces outils de manière autonome. - Ensuite, encourager et soutenir les apprentissages.
Nous avons créé une communauté DevOps au sein du département informatique pour partager et apprendre autour de nos valeurs DevOps fondamentales « qualité, vélocité, livraison ». Cette communauté a permis d’améliorer les relations entre les différentes équipes de l’organisation. Ainsi, nous avons pu créer et conduire des améliorations transversales qui ont donné lieu à des habitudes de collaboration. - Enfin, contribuer à une transformation plus large.
Nous avons également commencé à contribuer à un programme de transformation plus large autour de la chaîne de valeur afin de créer une visibilité sur le flux du changement et d’assurer un alignement de notre contribution avec la stratégie de l’entreprise.
Découvrez d’autres idées pour mettre en place du DevOps dans votre équipes.
Quel outil utiliser pour faire du DevOps : Platform as a Service (PaaS)*
La prochaine grande étape de notre transformation DevOps a été l’occasion de migrer une partie de nos services vers un cloud public et d’expérimenter le concept de PaaS pour les ingénieurs. L’idée est d’accroître l’autonomie des équipes et de réduire les frais de collaboration en standardisant l’interface de collaboration. Concrètement, notre équipe chargée du cloud a fait un excellent travail en fournissant des services standard aux développeurs sur Azure DevOps et AKS. Cela a permis aux développeurs de gérer le déploiement de leurs services en tant que code et de réduire la complexité de l’orchestration des conteneurs sur Kubernetes.
* Plateforme en tant que Service
Les défis du cycle de vie DevOps
Il y a encore quelques défis dans notre transformation DevOps.
- Tout d’abord, les KPI DevOps sont encore difficiles à mesurer avec les indicateurs DORA. Il y a plusieurs raisons à cela, mais nous pensons que cela deviendra plus simple au fur et à mesure que nous gagnons en maturité sur les pratiques DevOps.
- Notre deuxième défi est de pouvoir faire évoluer nos plateformes pour le concept de développeurs afin de fournir plus de services et d’étendre l’expérimentation à d’autres équipes.
D‘une organisation silotée à une organisation DevOps
Nous sommes passés d’une organisation silotée à une organisation capable de collaborer, créatrice de valeur, exploitant les meilleures pratiques DevOps et la Paas.
De plus, cette transformation DevOps a été possible car elle s’inscrivait dans un programme de transformation plus large. Je tiens à remercier mes managers pour leur confiance et leur investissement personnel dans cette transformation qui était une aventure et une expérience humaine.
Découvrez les autres contenus de l’Expertise Software Product Engineering
Grâce à nos
Auteur
