Exploiter la puissance de DevOps

Le Manifeste pour le développement agile de logiciels, publié en 2001, a permis de réaliser d’énormes progrès dans le développement de logiciels. Les méthodologies agiles ont permis à l’industrie de fonctionner dans des circuits de rétroaction plus courts et de travailler plus efficacement, permettant ainsi aux entreprises d’évoluer pour offrir le meilleur d’elles-mêmes.

Les initiatives agiles, toutefois, peuvent ne pas inclure le texte en petits caractères, pour ainsi dire. Dans la quête de brièveté et dans le désir de ne pas être trop prescriptive, la méthode agile peut être vendue ou interprétée comme une panacée. Livrer plus rapidement, établir des équipes plus performantes et élaborer de meilleurs logiciels : voilà des objectifs nobles, mais la prudence l’est tout autant. Ces paroles peuvent sembler controversées, mais c’est aussi la réalité. Il sera toujours possible d’améliorer les systèmes existants ou de rechercher de nouvelles technologies, mais il est essentiel d’équilibrer et de hiérarchiser les efforts, même si c’est difficile, pour réaliser de véritables progrès.

La mise en œuvre de DevOps permet de rationaliser cet exercice d’équilibre et de concrétiser davantage d’aspects du Manifeste Agile. DevOps permet l’intégration du développement et de l’exploitation pour livrer de meilleurs logiciels plus rapidement. Mais lorsqu’un test automatisé échoue et que les pipelines de build passent au rouge, les intentions du logiciel se manifestent et révèlent le développement axé sur le comportement qui a servi à sa création. Toutefois, lorsqu’elles déploient le DevOps en particulier, les entreprises doivent faire attention de ne pas perdre l’interaction avec les individus au profit de la recherche d’outils et de processus. Votre réponse au changement en dit plus long que la rapidité avec laquelle vous pouvez changer 10 serveurs à la fois.

Avec DevOps vient l’expérimentation. Il est impératif d’être agile dans ses approches à des solutions et de reconnaître que tous les chemins ne mèneront pas au succès. Le contexte est donc essentiel. Et comme tout cadre de travail agile, DevOps nécessite l’adhésion. Même si les équipes de développement et d’exploitation travaillent en harmonie, cela ne sert pas à grand-chose si la culture s’arrête à la porte métaphorique du sous-sol réservé aux services informatiques. Sans le soutien de l’ensemble de l’organisation, l’amélioration continue se limitera au fonctionnement interne d’un seul groupe. Pour paraphraser le conseil que l’on entend sur les modes de vie sains, « ce n’est pas une mode, c’est un changement de style de vie ».

La compréhension cruciale et l’appropriation partagée de l’engagement à l’égard de DevOps sont incidemment ce qui manque le plus dans les efforts de DevOps. Quand on parle de la communauté au sens large, on a souvent l’impression que les outils sont la clé, et qu’une fois en place, on atteint un état d’illumination. Ce sentiment a changé. Par exemple, de nos jours, les gens réalisent que ce ne sont pas les outils à eux seuls qui font d’excellents sites Web, mais ce sont les équipes de collaborateurs travaillant main dans la main qui contribuent à une excellente expérience numérique ; cette même approche doit être appliquée à DevOps.

Les technologies, comme le cloud, sont de brillants exemples de ce que DevOps peut accomplir, mais elles en sont aussi des facilitateurs. Il est vrai que DevOps offre une sécurité et une extensibilité intégrées, mais il annonce aussi une plus grande capacité de collaboration. De plus en plus d’entreprises se servent d’outils de collaboration et envisagent toujours plus de scénarios hypothétiques. Les sites Web et les applications pour téléphone personnalisables sont d’excellents exemples de la façon dont les codes simplifiés (« low code ») peuvent étendre les technologies de l’information aux petites entreprises, mais il est également important d’en comprendre les limites.

Rapides et faciles à utiliser, les interfaces utilisateur donnent l’impression que les possibilités sont infinies, en particulier les moteurs de workflow et toutes sortes de nouveaux outils d’automatisation visuelle. Mais laissez-moi vous donner un bon conseil : lorsque vous êtes forcé de jouer au « jeu des sept différences » entre des captures d’écran parce que vous ne disposez pas d’option d’exportation pour vos données, il est temps de choisir un outil différent pour faire le boulot. L’expérience est utile et l’apprentissage des autres réduit la courbe d’apprentissage et raccourcit le circuit de rétroaction entre vous et votre client. C’est cela qui est l’essence même de DevOps.

Pour en savoir plus sur notre solution de DevOps Géré, cliquez ici.