Comme les pratiques DevOps peuvent apporter un gain important de rapidité et de fiabilité au cycle de vie de la livraison de logiciels, la gestion des publications peut sembler intimidante. Mais l’amélioration de la visibilité et de la collaboration que l’on doit au DevOps peut également contribuer au processus de gestion des publications. Bien que le concept général de la gestion des publications ne varie pas vraiment entre l’ITIL (bibliothèque d’infrastructure informatique) et le DevOps, le processus diffère à plusieurs égards.
Déjà, l’ITIL est un modèle spécifique de processus pour les opérations IT, tandis que le DevOps s’améliore constamment. De plus, il n’y a pas d’approche unique de l’implémentation du DevOps, tandis que l’ITIL est un ensemble d’instructions à suivre. Le problème de l’ITIL est que chaque équipe fonctionne différemment : vous ne pouvez donc pas avoir une approche unique des opérations IT et de la gestion des publications.
La gestion des publications centrée sur le DevOps est l’avenir du développement logiciel et des opérations IT. Nous avons donc rédigé cet article pour définir quelques bonnes pratiques de gestion des publications DevOps et suggérer des outils pour aider votre équipe à maintenir des calendriers de déploiement courts pour des logiciels fiables.
Qu’est-ce que la gestion des publications ?
Dans le développement logiciel et les opérations IT, la gestion des publications est un système qui gère l’ensemble du cycle de vie de la livraison de logiciels, de la planification au déploiement en passant par le développement et les tests. Pour l’ITIL comme pour le DevOps, il s’agit du processus général. Cependant, le DevOps encourage la collaboration et la visibilité tout au long du processus de livraison, en raccourcissant les boucles de feedback et en encourageant la simplification et l’accélération de la gestion des publications.
Voyons comment la gestion des publications se manifeste chez les équipes ITIL et DevOps :
Gestion des publications ITIL
Dans l’ITIL, le processus de gestion des publications consiste à planifier et à maintenir l’intégrité des nouveaux déploiements, de la planification à la publication. L’équipe ITOps reçoit le code des développeurs logiciels et décide quand et comment fournir le service tout en maintenant la disponibilité des services existants.
Gestion des publications DevOps
Dans un contexte DevOps, la gestion des publications concerne également la planification, la programmation et le contrôle du processus de développement et de livraison des logiciels. Mais dans le DevOps, les développeurs et les opérations IT collaborent du début à la fin du processus, ce qui réduit le nombre de boucles de feedback et accélère la publication des versions.
Les équipes DevOps partagent la responsabilité des services qu’elles fournissent, pilotent leur code et assument des responsabilités d’assistance d’astreinte. Lorsque des développeurs logiciels et des professionnels de l’IT sont impliqués dans l’ensemble du cycle de vie de la livraison et dans l’assistance d’astreinte, les incidents sont détectés et résolus plus rapidement, à la fois pendant le processus de publication et après.
Passons donc en revue quelques notions clés de la philosophie DevOps et voyons comment elles s’appliquent aux bonnes pratiques de gestion des publications :
Bonnes pratiques DevOps de gestion des publications
Définir les critères de réussite
Comment savez-vous à quel moment du code est prêt à être publié ? Des critères d’acceptation clairs, concernant tant les versions que les tests, permettront de livrer des versions plus fiables. Les critères d’une version réussie ne peuvent pas être subjectifs. Autrement, vous n’avez pas la possibilité d’apprendre de vos erreurs et de continuer à itérer sur le processus de gestion des publications pour l’optimiser. Les responsables des produits, de la qualité et des publications doivent définir des paramètres clairs et convenir des critères d’acceptation avant de faire avancer un nouveau projet.
Chercher constamment à avoir un impact minimal sur l’utilisateur
Naturellement, les bons responsables des publications cherchent constamment à réduire les temps d’arrêt et l’impact sur les clients. Les tests proactifs, la supervision active et les alertes collaboratives en temps réel peuvent vous aider à identifier les problèmes au cours d’une publication, bien avant qu’un client ne s’en aperçoive. Couplée à un plan collaboratif de réponse aux incidents, cette approche permet de résoudre rapidement les incidents et de parvenir à une version réussie.
Tirez le meilleur parti de votre environnement de staging
L’entretien soigneux de l’environnement de staging, qui doit le maintenir aussi proche que possible de votre environnement de production, peut garantir des versions de meilleure qualité. Toutes les personnes concernées, des propriétaires de produits à la QA, devraient passer au peigne fin la mise en place et l’exécution des tests afin d’identifier tout problème lié à un nouveau déploiement. Tant que votre environnement de staging est quasiment identique à la production, vous détecterez facilement les problèmes avant de déployer le code en production. Un environnement de staging bien conçu réduira l’impact sur les clients et aidera les équipes DevOps à faire en sorte que les versions répondent plus rapidement aux critères d’acceptation.
Rationalisation du CI/CD et de la QA
L’idée de décalage vers la gauche est courante dans le DevOps. En déplaçant la QA, l’automatisation et les tests vers l’amont du cycle de vie du développement, l’équipe DevOps peut identifier plus rapidement les problèmes potentiels. Elle réduit ainsi le temps passé dans les boucles de feedback et permet au pipeline de livraison de continuer à avancer. Plus vous pourrez intégrer les tests aux workflows de développement, plus il sera facile de maintenir un pipeline CI/CD cohérent.
Utilisez l’automatisation à votre avantage
Règle numéro un dans le DevOps : automatisez tout ce qui peut améliorer l’efficacité de vos équipes, de vos processus et de vos technologies. Que ce soit du côté du développement logiciel, de la QA ou des opérations IT, l’automatisation doit servir à réduire les erreurs humaines et faciliter les opérations quotidiennes de vos équipes. En donnant à votre équipe la possibilité de consacrer plus de temps à la réflexion stratégique qu’aux tâches quotidiennes, vous serez à même de fournir systématiquement des services fiables à vos clients.
Rendez les choses immuables quand vous le pouvez
En programmation, l’état d’un objet immuable ne peut pas être modifié après sa création. La programmation immuable amène les équipes à déployer des configurations entièrement nouvelles au lieu de modifier l’existant, ce qui peut réduire les erreurs et les bugs qui pourraient apparaître en modifiant les configurations actuelles. Cela rend les versions intrinsèquement plus fiables, et améliore donc la satisfaction des clients et des collaborateurs.
La gestion des publications DevOps est centrée sur les personnes
Les processus DevOps conduisent naturellement à une meilleure structure de la gestion des publications, en instaurant des bonnes pratiques de collaboration et de test tout au long du cycle de livraison. Si l’on se focalise souvent sur l’automatisation comme la valeur clé du DevOps, l’automatisation doit toujours viser à améliorer l’efficacité de votre personnel. Lorsque les équipes réduisent la part de l’erreur humaine et créent de l’efficacité opérationnelle, elles se mettent naturellement à livrer des services fiables rapidement.
Ces bonnes pratiques de gestion des publications DevOps ne sont qu’un point de départ. La technologie évolue, les gens se forment, et nos processus de gestion des publications doivent également changer. L’amélioration continue des personnes, des processus et de la technologie est essentielle à toute structure réussie de gestion des publications DevOps.
Splunk Observability Cloud fournit aux équipes DevOps les outils de supervision et d’alerte de bout en bout dont elles ont besoin pour réussir. Découvrez notre essai gratuit de 14 jours pour savoir comment nous pouvons aider votre équipe à réussir.
*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.
