dim. Déc 15th, 2019

3 erreurs fréquentes à éviter pour optimiser votre approche DevOps

cloudbees - brian dawson

Une exclusivité Les-experts.tech

Par Brian Dawson, évangéliste et spécialiste DevOps chez CloudBees

Lorsqu’une approche DevOps est correctement adoptée, les équipes travaillent ensemble de manière harmonieuse, les outils sont utilisés au bon moment et au bon endroit, les applications suivent l’enchaînement prévu et toutes les parties prenantes sont satisfaites des résultats. 

Mais quiconque a conçu une telle pratique sait que les choses ne se déroulent pas toujours comme prévu. Même si les équipes impliquées ont généralement les meilleures intentions, l’exécution des stratégies DevOps demeure problématique. 

Quelle est l’origine de ces complications ? Et que faire pour les éviter ou les résoudre ? Voici 3 erreurs fréquentes commises lors de la mise en place d’un tel processus.

 

1.La confrontation des équipes

On a beaucoup écrit ces dernières années sur les bienfaits de l’élimination des silos. Les entreprises de tout secteur tentent aujourd’hui de réorganiser les services pour les amener à communiquer davantage, à mieux partager l’information, à rationaliser les processus décisionnels et à s’aligner sur des objectifs communs.

Ce type d’échange est particulièrement important dans le cadre d’une approche DevOps, mais n’est pas toujours simple à mettre en place.

Les équipes Dev et Ops sont généralement en désaccord de par leurs approches divergentes. Les développeurs sont des créatifs qui repoussent les limites du code et explorent chaque problème rencontré alors que les équipes en charge des opérations sont plus rigides et résistent au changement.

En plus de devoir s’accorder sur ce point, les professionnels Dev et Ops doivent aussi travailler étroitement avec la partie métier de l’entreprise. La réussite DevOps dépend ainsi du niveau de collaboration général.

Les conflits internes créent de la tension, avec des passages de relais difficiles entre les équipes. Ils se matérialisent souvent au niveau du processus de déploiement et du logiciel lui-même pour des causes d’écarts de qualité, d’expériences utilisateur incohérentes et d’autres divergences d’opinions.

Les entreprises ont tout intérêt à admettre le lien entre la culture interne et la réussite DevOps et à agir en ce sens. Il leur faut alors penser alignement, communication et inclusion.

 

2.Des KPI mal définis

La façon dont une équipe définit la réussite la conditionne. Les KPI peuvent, par exemple, confirmer qu’une équipe fait du bon travail mais s’ils sont mal définis, l’initiative risque d’échouer. Comme pour tout projet, il convient de communiquer sur les métriques en jeu et il est plus pertinent de les redéfinir pour chacun d’entre eux plutôt que de les dupliquer aveuglement.

Si l’on en revient à la communication entre les services et à l’élimination des silos, il faut également que les KPI utilisés par les développeurs soient liés à un KPI métier, comme le nombre de nouveaux clients ou le pourcentage d’augmentation des recettes. Ceci est un gage de rapidité et d’efficacité général des équipes et fait plus de sens que d’imposer une cadence ingérable pour les différents services.

Par exemple, si une équipe d’ingénieurs qualité souhaite mesurer la rapidité, elle devra créer une métrique basée sur le nombre de tests exécutés par cycle. Les individus ont besoin de motivations et une équipe a naturellement tendance à ajouter toujours plus de tests sans archiver ceux devenus obsolètes. Et si l’équipe tentait de fonctionner avec moins de tests ? Leur réduction limiterait le temps alloué au cycle et permettrait à l’équipe de soigner le périmètre et l’efficacité des tests, plutôt que de se concentrer sur leur seule quantité.

 

3.Un déploiement trop rapide du code

Parfois, les équipes décident d’exécuter des applications qui n’ont pas été correctement testées. Elles devraient pourtant traiter les pipelines de déploiement continu (CD) comme des applications et rechercher et éliminer les erreurs dans le code. A défaut, elles s’exposent à l’augmentation des coûts et des risques.

Il arrive également que les équipes fonctionnent en parallèle lors des cycles CI/CD, ce qui a pour effet d’accélérer les tests automatisés et de raccourcir les cycles de feedback. Pour éviter cela, l’entreprise doit veiller à ce que les déploiements ne s’opèrent pas en parallèle. Cette erreur de configuration induit le déploiement du code au moment même où les tests sont exécutés et ne tient pas compte des codes de sortie. Cela va alors à l’encontre de l’objectif visé par l’automatisation des tests préalables au déploiement.

Les équipes devraient plutôt envisager de créer des environnements de staging. A commencer par le côté gauche du process, build, puis dev, test et déploiement. Il est possible que les équipes ne parviennent pas à définir une solution d’automatisation idéale du premier coup, mais le fait de progresser de gauche à droite les encourage à analyser le cycle de vie d’un artéfact. 

Ensuite, les équipes devraient définir leur pipeline CD selon une approche « everything-as-code » ou « pipeline-as-code ». Et enfin, il convient d’établir les environnements de staging ou les pipelines de test pour valider le processus CD.

En suivant ces étapes, les équipes auront l’occasion d’opérer des changements dans le code des applications, de faire des analyses initiales et de collaborer à la définition du pipeline de Continuous Delivery.

 

Pour limiter ces erreurs lors de l’adoption d’une approche DevOps, il faut donc collaborer, définir les bons KPIs et coder dans le bon ordre. Garder ces points en tête peut vous permettre de résoudre vos problématiques ou d’éviter les pièges DevOps.

Les opinions exprimées dans cet article sont uniquement celles du contributeur
et ne reflètent pas celles de Les-Experts.tech.

%d blogueurs aiment cette page :