Un pipeline de mise en production avec étapes de promotion et d'approbation pour une équipe e-commerce

Les programmes DevOps s'enlisent quand l'outillage ne correspond pas à l'organisation. Une équipe sur la pile Microsoft tire peu de profit d'un pipeline conçu autour d'un autre écosystème, et un pipeline qui ne couvre qu'une partie du cycle de vie laisse en place les étapes manuelles, là où surviennent réellement les retards et les erreurs.

BuildDirect avait besoin d'un parcours que ses propres développeurs utiliseraient au quotidien : un parcours qui mène un changement du commit au build, aux tests et à la mise en production sans passage de relais, et qui s'accorde avec les outils et les compétences déjà en place. Les responsables du programme devaient aussi voir la livraison fonctionner concrètement.

SEYA a commencé par une évaluation approfondie des objectifs et des besoins métier de BuildDirect. Les applications qui devaient transiter par le pipeline, la façon dont les mises en production étaient approuvées, les différences entre environnements et les étapes encore réalisées à la main ont toutes orienté la conception.

À partir de cette évaluation, SEYA a conçu un pipeline de livraison sur la pile Microsoft, en choisissant des outils que les ingénieurs de BuildDirect pourraient s'approprier après la mission plutôt qu'en introduisant une chaîne d'outillage parallèle.

SEYA a mis en œuvre un pipeline CI/CD couvrant tout le cycle de développement logiciel. Team Foundation Server héberge les sources et exécute les builds, et Octopus Deploy orchestre les mises en production à travers les environnements, avec les étapes de promotion et d'approbation dont BuildDirect avait besoin.

Là où les outils du commerce s'arrêtaient, SEYA a écrit une automatisation PowerShell et des scripts Node.js sur mesure, de sorte que les étapes d'empaquetage, de configuration et de déploiement qui auraient autrement été manuelles font partie du pipeline et s'exécutent de la même façon à chaque fois.

Pour un responsable informatique ou un directeur de l'ingénierie, le changement tient à l'endroit où va l'effort. Les déploiements cessent d'être des événements qui exigent la disponibilité de la bonne personne et deviennent une étape de pipeline que n'importe quel membre de l'équipe peut déclencher et tracer.

Parce que le pipeline couvre tout le cycle de vie, il existe un seul registre de ce qui a été construit, à partir de quel commit et où cela a été déployé. C'est ce que demandent un auditeur, un ingénieur support ou un product owner quand quelque chose tourne mal ou qu'une fonctionnalité doit être vérifiée en production.

S'appuyer sur des outils que l'équipe utilisait déjà a permis de maintenir le pipeline en interne après la mission, moment où un programme DevOps cesse d'être un projet pour devenir une manière de travailler.