Une version de VetCoreSolution® est prête… que se passe-t-il ensuite ?
Avant d’arriver dans une clinique, chaque version traverse cinq étapes de contrôle qui permettent de prouver son origine, son contenu et les tests qu’elle a franchis.
Pierre Bony
Président, cofondateur et CTO
On copie simplement quelques fichiers sur un serveur ? Pas vraiment.
Chez VetCoreSolution®, déployer consiste à faire passer une version précise à travers une chaîne de contrôles, tout en restant capable de prouver d’où elle vient, ce qu’elle contient et quels tests elle a traversés.
Et tout cela tient en cinq grandes étapes.
Le code de chaque composant — applications web, serveurs et services — est d’abord conteneurisé séparément. Comme un conteneur sur un bateau, chaque image est standardisée, scellée, identifiée et transportable d’un environnement à l’autre sans que son contenu change.
Étape 1 — Le code ne monte pas à bord sans contrôle
Chaque proposition de modification du code déclenche automatiquement une batterie de tests.
Nous reviendrons sur les tests dans un prochain PointTech : le sujet mérite largement son propre épisode.
Étape 2 — Fabriquer et identifier les conteneurs
Lorsqu’une nouvelle version est déclarée, notre chaîne d’intégration continue — la CI, cette usine automatisée qui fabrique les versions à partir du code — construit les images correspondantes.
Elle les dépose ensuite dans notre registre de conteneurs : notre terminal portuaire numérique. Chaque image y est stockée, identifiée et prête à être déployée. Ses métadonnées permettent de retrouver précisément la version concernée et le code qui l’a produite.
L’image reçoit également une signature numérique avec Cosign. Nos environnements peuvent ainsi vérifier qu’elle provient bien de notre chaîne de construction et qu’elle n’a pas été remplacée ou altérée.
Étape 3 — Dire « latest » ne veut pas dire « production »
Chaque nouvelle image reçoit d’abord l’étiquette « latest ». Chez nous, cela signifie : voici la version la plus récente à éprouver.
Chaque nuit, les images « latest » sont déployées sur des serveurs réservés à la validation, aussi appelés grappes ou clusters. Des tests s’y exécutent durant toute la nuit afin d’observer le comportement, la stabilité et les performances de la plateforme.
Étape 4 — Promouvoir, sans reconstruire
Lorsque les résultats sont satisfaisants, nous ne reconstruisons pas une nouvelle image. Nous prenons exactement celle qui a passé les tests et nous la promouvons en lui attribuant l’étiquette « prod ».
Pour les plus techniques : son digest ne change pas. C’est strictement le même contenu, simplement autorisé à partir vers la production.
Étape 5 — Le déploiement final
À la demande ou durant une campagne nocturne, notre chaîne de livraison orchestre l’installation sur la grappe de serveurs de production. Elle vérifie que les services démarrent correctement, que la plateforme répond et que les contrôles finaux sont validés.
Ce n’est qu’à ce moment-là que la nouvelle version est libérée.
Pourquoi toutes ces étapes ?
Parce que nous devons pouvoir répondre, à tout moment, à trois questions simples :
- Quel code est actuellement exécuté ?
- Quelle image le transporte ?
- Quels contrôles cette image a-t-elle traversés ?
