La culture DevOps repose sur une transparence, une communication et une collaboration accrues entre des équipes travaillant traditionnellement en vase clos. Mais d’importants changements culturels doivent être opérés pour les rapprocher. Ce changement de culture organisationnelle met l’accent sur l’apprentissage et l’amélioration continus, notamment grâce à l’autonomie des équipes, à un retour d’information rapide, à une empathie et une confiance élevée.
Pour autant, si le DevOps est rendu possible par de nouveaux outils et des pratiques d’ingénierie agiles, ceux-ci ne suffisent pas à en tirer les bénéfices. Sans l’état d’esprit, les rituels et la culture appropriés, il est difficile de réaliser toutes les promesses du DevOps.
Des défis à relever
L’adoption complète d’une culture DevOps exige généralement que les individus et les équipes apportent des changements importants à leur manière de travailler, et nécessite donc l’adhésion des dirigeants de l’entreprise.
Un effort de base peut être, et représente souvent, un point de départ important pour obtenir l’adhésion de la direction et des managers à une transformation DevOps. Souvent, l’argument le plus convaincant en faveur d’une adoption plus large de DevOps est soutenu lorsque quelques individus ou équipes à taille humaine adoptent une approche DevOps et commencent à faire preuve de succès.
Les niveaux élevés d’autonomie et de confiance typiques d’une culture DevOps peuvent être difficiles à cultiver s’il y a des antécédents de conflit entre les personnes ou les équipes concernées. Plus les équipes étaient cloisonnées avant de tenter d’adopter une telle approche, plus il sera difficile de créer des liens.
Même dans les environnements les plus fluides entre les individus et les équipes en place, si les avantages du changement ne sont pas clairement articulés et compris, il peut être difficile de susciter l’acceptation et la volonté de passer à l’action.
La tentation est forte pour les entreprises appartenant au secteur de l’ingénierie et la tech de se tourner immédiatement vers des outils et des technologies qui peuvent aider à passer à une approche DevOps. Mais changer les outils et les technologies sans changer la culture auparavant correspondrait à changer la façade d’un bâtiment sans s’attaquer aux faiblesses de ses fondations.
Le droit à l’erreur
De nombreuses entreprises, équipes et collaborateurs s’imposent une pression extraordinaire pour éviter à tout prix les erreurs. Si l’échec n’est pas une option, un individu ou une équipe est moins susceptible de tenter une nouvelle approche pour résoudre un problème ou développer des fonctionnalités innovantes.
Cet état d’esprit se reflète dans la vieille obsession de mesurer le « temps moyen entre les défaillances » (MTBF) plutôt que le « temps moyen de récupération » (MTTR). Le MTBF utilise des outils tels que « l’analyse des causes profondes » pour identifier la source des défaillances et tenter de les empêcher de se reproduire. Le MTTR reflète une vision des applications logicielles comme des systèmes complexes susceptibles de tomber en panne de manière imprévisible et se concentre sur une récupération rapide en cas de panne.
Une « rétrospective sans reproche » est une caractéristique commune de la culture DevOps. Les résultats peuvent être améliorés lorsqu’une équipe se réunit à la fin d’un projet pour discuter de ce qui s’est bien passé et de ce qui pourrait être amélioré, dans un environnement ouvert et sûr.
La refonte des processus
Pour cultiver une culture DevOps, il faut développer de nouvelles approches pour les anciennes problématiques. DevOps implique de changer le processus cloisonné des développeurs qui écrivent le code de l’application et l’“abandonne” à une équipe d’exploitation qui déploie et exploite l’application. L’approche DevOps implique que le développement et les opérations travaillent ensemble tout au long du cycle de vie d’un projet.
L’intégration continue et la livraison continue (CI/CD) sont généralement considérées comme nécessaires. Un troisième processus, le déploiement continu, est adopté et promu par des sociétés telles que Netflix, mais n’est pas communément adopté (ou requis) dans la plupart des petites entreprises. En effet, le déploiement continu de nouvelles fonctionnalités dans un environnement de production exige un degré élevé de confiance dans le fait que le nouveau code a été testé de manière approfondie et qu’il peut être déployé en toute sécurité (par exemple, derrière une bascule de fonctionnalité). Ainsi, à moins qu’une entreprise ne déploie plusieurs fois par jour, il n’est peut-être pas utile d’investir dans les processus qui soutiennent cette approche.
Une chaîne d’outils actualisée
La plupart des équipes de développement logiciel utilisent au moins un certain type d’outils de contrôle de version, de suivi des problèmes et de surveillance des applications. Tous ces outils sont importants pour soutenir une culture DevOps, mais l’ajout le plus important à la panoplie d’outils traditionnels est sans doute le logiciel qui prend en charge le CI/CD. Disposer d’un flux de travail automatisé qui prend un commit, le teste et le déploie est vraiment le seul moyen d’obtenir le retour d’information rapide qu’exige une culture DevOps.
Récolter ce que l’on sème
Depuis des décennies, les développeurs poursuivent le rêve de livrer des logiciels plus rapidement, plus facilement avec moins de bugs. Aujourd’hui, les outils et les pratiques permettant d’en faire une réalité sont enfin disponibles. Mais il ne s’agit pas simplement d’adopter la planification Agile, les tests automatisés ou la livraison continue. La culture DevOps implique une compréhension commune entre les équipes de développement et opérationnelles, et la responsabilité partagée des logiciels développés. Cela signifie accroître la transparence, la communication et la collaboration au niveau des équipes de développement et opérationnelles informatiques, mais aussi à l’échelle de toute l’entreprise.
Instaurer une culture DevOps peut être un défi, mais les récompenses en termes de satisfaction pour les développeurs, les managers et les clients en valent la peine.
___________________
Par Tristan Ouin, Head of Atlassian France