Pour rester compétitives, les entreprises s’attachent à développer des logiciels de la bonne manière, en suivant les principes de l’intégration continue et du déploiement continu, ainsi que de DevOps. Tandis que l’intégration continue repose sur l’automatisation, la création de builds et les modifications rapides, le déploiement continu consiste quant à lui à faire progresser le code dans le pipeline. Le DevOps associe ces deux principes et vise à transformer la culture d’entreprise pour encourager et promouvoir la collaboration entre les services.

En effet, chaque organisation souhaite réussir et atteindre ses objectifs de développement dans tous les projets. Néanmoins, cet accomplissement se fait rarement de façon directe, et demande du temps et des efforts collectifs. Le rôle du DevOps est de laisser la place à l’échec et de faire en sorte qu’en cas d’erreur de votre part, vous puissiez réagir rapidement et en tirer des leçons. Vous pouvez alors vous appuyer sur les informations récoltées afin d’améliorer votre processus à l’avenir.

Toutefois, s’il existait des moyens d’éviter certaines erreurs, peut-être qu’un certain nombre d’entreprises seraient en mesure de progresser et d’apprendre plus vite. Dans le cadre de cette philosophie DevOps, les équipes sont ainsi susceptibles de se heurter à un certain nombre d’erreurs fréquentes. Voici quelques-unes de ces erreurs, ainsi que des conseils pour en tirer des leçons.

Problèmes DevOps courants et solutions pour les éviter

1) Verrouillages inattendus

Il arrive assez facilement aux développeurs de bloquer eux-mêmes leur accès lors de l’automatisation des déploiements selon un modèle « configuration as code » (configuration sous forme de code). Lorsqu’une modification incorrecte est transmise et déployée sur toutes les machines, ce problème les oblige alors à se connecter manuellement à chaque machine pour corriger l’erreur.

Comment éviter le problème : les développeurs doivent mettre en place des protections et une configuration de validation adéquates, et faire en sorte que toutes les modifications soient appliquées de façon régulière dès les premières étapes du développement. En mettant en place un processus officiel pour les modifications de code d’infrastructure et de code d’application, les entreprises réduiront le risque d’incidences sur d’autres environnements, ce qui permettra de faire gagner du temps aux développeurs et d’améliorer la qualité du projet.

2) Déploiement prématuré

Souvent, les développeurs exécutent l’intégration continue et le déploiement continu en même temps afin d’accélérer les cycles de test et de retour automatisés. Lorsque vous fonctionnez de cette manière, l’erreur courante à éviter est d’exécuter également le déploiement. Car le code serait alors configuré de façon inappropriée et les modifications seraient appliquées au produit final avant d’avoir été testées, ce qui ferait perdre tout l’intérêt des tests automatisés avant déploiement.

Comment éviter le problème : il est essentiel de mettre en place des validations et des contrôles avant que le moindre code ne soit accessible par l’utilisateur final. Vous pouvez par exemple créer vos pipelines de déploiement continu de telle sorte que les tests parallèles soient gérés comme une étape de validation avant transmission vers l’environnement de production. Vous pourrez ainsi être sûr que les modifications testées et validées ne sont pas déployées automatiquement.

Si, selon les principes de DevOps, les équipes doivent être en mesure de déployer à tout moment, le déploiement doit cependant toujours être géré et survenir à la fin du pipeline, c’est-à-dire après que tous les tests, contrôles de validation et approbations ont été effectués et avant qu’il n’atteigne le client.

3) Conflits de gestion de configuration logicielle

La gestion de configuration logicielle (GCL) représente l’un des principaux défis que rencontrera une équipe DevOps. Il n’est pas rare qu’au début de leur carrière, les architectes informatiques se voient accorder l’accès à des référentiels Git (système de suivi de contrôle des versions et de gestion du code source), ce qui ne manquera pas de créer des problèmes. Lorsque les équipes tenteront de maîtriser les principes de base de Git, elles rencontreront probablement des conflits de fusion, impliquant un ou plusieurs conflits dans le programme, et des références HEAD détachées (lorsqu’un commit spécifique est basculé au lieu d’une branche). Or, non seulement il est difficile de s’en défaire, mais toutes les modifications apportées dans ce mode seront perdues.

Comment éviter le problème : il est préférable de mettre en place un modèle de fusion et de branches pour faire en sorte que les bonnes informations soient intégrées au pipeline de DevOps et permettre ainsi l’intégration continue des tests et des modifications de déploiement.

4) Objectifs mal définis

Bien que les développeurs collaborent pour faire avancer le code dans le pipeline, il arrive que différentes équipes définissent leurs propres indicateurs clés de performances. Par exemple, une équipe d’ingénieurs qualité peut utiliser le nombre de tests exécutés par sprint comme mesure de réussite. Or, dans la mesure où les employés sont presque toujours rémunérés au résultat, ils peuvent avoir naturellement tendance à ajouter toujours plus de tests, sans forcément se soucier de savoir s’ils sont obsolètes. Cela pourrait avoir une incidence sur les autres équipes et augmenter la durée du cycle de test, ainsi que celle de la mise en production.

Comment éviter le problème : bien cet aspect soit trop peu souvent abordé, comprendre le « pourquoi » de DevOps est essentiel. Les entreprises doivent définir des buts et des objectifs pour chaque initiative, et faire en sorte que toutes les équipes s’alignent dessus. Une fois les buts définis, les indicateurs clés de performances et les mesures de réussite peuvent être alignés sur les objectifs. Les entreprises doivent développer un ensemble de buts, de mesures de réussite et d’indicateurs clés de performances communs, afin de permettre une définition claire des priorités lors de la création des pipelines.

5) Mauvaise identification des barrières organisationnelles

La culture d’entreprise est souvent l’une des difficultés que rencontrent les organisations. Faute d’intégrer pleinement vos équipes, vous risquez de créer de nouveaux silos et de diviser les services. Cela peut poser des problèmes lors d’un développement interne, car les services se rejettent souvent la responsabilité les uns sur les autres au lieu d’évaluer l’entreprise dans son ensemble.

Comment éviter le problème : la meilleure manière d’organiser les équipes est de le faire par sujets, tels qu’un produit ou une fonctionnalité. De plus, toutes les parties prenantes doivent être incluses dès le début du processus de développement afin que le rôle des différentes équipes soit clairement défini. L’ensemble des parties prenantes et des équipes de développement seront ainsi sur la même longueur d’onde, et l’entreprise pourra réellement pratiquer le DevOps. La culture DevOps est tout aussi importante que les technologies et les outils utilisés pour le développement de logiciels, bien qu’elle soit difficile à faire émerger.

Lorsque l’on étudie les erreurs courantes rencontrées lors de la mise en œuvre de DevOps, il est essentiel de reconnaître que toutes les entreprises sont différentes. Par conséquent, chacune d’elles connaîtra une transition DevOps différente et ses propres mésaventures. Il n’existe aucun moyen simple de réussir une transformation DevOps, ni de la réaliser rapidement. Le DevOps apportera toujours son lot de difficultés et d’erreurs, et votre succès dépend donc de votre capacité à apprendre et à vous adapter. Ce n’est qu’en développant ces deux qualités que les entreprises seront capables de créer leur propre culture DevOps.

_________
Brian Dawson est un spécialiste de DevOps chez CloudBees.
Contributeurs de l’article : Carlos Sanchez, Laura Frank Tacho, Will Refvem, Juni Mukherjee, Viktor Farcic.