Releases Management RSS

Cette page décrit le processus de gestion des mises en production de la plate-forme eHealth.

Vous y trouverez 

• un aperçu du calendrier des mises en production 
• les conventions d'appellation des différentes phases d’une release 
• une explication des mises en production progressives et des ‘Availability zones’ (AZ) 
• les phases du processus 
• des définitions claires des termes utilisés

Ces informations constituent un guide pratique pour les partenaires et les parties prenantes.

Le tableau ci-dessous reprend les dates des prochaines Releases prévues, ainsi que les dates de début des tests en acceptation.

Nomenclature du versioning

Chaque version suit une logique de nommage fixe :

AAAAAx.a

• AAAA : Année civile
• x : Version majeure
• a : Version mineure

Exemples

R20261 = la première version majeure de l’année 2026

R20261.2 = la deuxième version mineure après la première version majeure de l’année 2026

Définitions

• Type de release
  • Release mineure
    • mise en production de services mineurs 
    • maintenance et corrections évolutives 
    • aucune modification fondamentale de l’architecture
  • Release majeure
    • mise en production d’une nouvelle version du connecteur 
    • mise en production de nouveaux services de base eHealth 
    • modifications structurelles ou architecturales
• Le content proposal
  • Le content proposal est l'ensemble des informations utiles au démarrage d'un projet. Pour connaître quelles informations sont requises, il y a lieu de prendre contact avec l'équipe de gestion des projets via l'adresse mail ehealthppkb@ehealth.fgov.be afin de faire l’analyse d’impact éventuel sur le développement (ou pas) de nouveaux services de base à planifier dans une release . Le content proposal doit être complet pour la date indiquée dans le tableau ci-dessus.
• Le content freeze
  • Plus aucune modification n’est apportée au contenu de la release en cours
  • Le contenu de la version est définitif
• Le code freeze
  • Plus aucune modification n’est apportée au code de la release en cours
  • Seules les corrections strictement nécessaires peuvent encore être prises en compte
• Début des test en ACC
  • Il est demandé aux partenaires et aux fournisseurs de logiciels d’effectuer des « sanity tests » dans l’environnement d’acceptation et si besoin de remonter les problèmes rencontrés via le support de la plate-forme eHealth
• Release day
  • Date de la mise en production de la release sur les deux AZ (IN 95% et UP 5%). Conformément au principe du ‘canary release’(*)
• Interventions de configuration
  • Ces interventions reprennent uniquement les différentes configurations provenant soit d’une demande de support soit d’une demande liée à un projet (voir point 5)
• Release
  • Une release contient les différents types de développement ainsi que les maintenances évolutives des services existants

Processus

Ci-dessous vous trouverez les étapes importantes du processus release management appliqué par la plate-forme eHealth.

Depuis le passage en juin 2021 sur notre nouvelle infrastructure, composée de deux AZ (Availability zone), le trafic est réparti par défaut à 95% sur l’AZ IN et 5% sur l’AZ UP.

Chaque nouvelle mise en production se fera en mode « Canary release (*)». Dans le calendrier ci-dessus vous trouverez deux dates par environnements (AZ UP et AZ IN). Ces dates correspondent à la mise en ACC et PRD de la release .

(*)Explication du mode « canary release » :

Notre nouvelle infrastructure est composée de deux AZ (Availability zone) qui nous permettent de

1. mettre la nouvelle version de la release sur une de ces AZ (par défaut l’AZ UP)
2. ensuite libérer le trafic petit à petit sur cette AZ (UP) contenant  la nouvelle release
3. mettre à jour l’autre AZ (IN) avec la nouvelle release

Phases du processus

Mise en production release (1*)

(1*) ce planning est susceptible d’être légèrement modifié en fonction de l’état d’avancement des déploiements de la release.
Vous trouverez ces potentiels changements sur le site eHealth Status.

(2*) Lorsqu’une intervention avec impact doit être réalisée lors d’une release, elle sera planifiée le dimanche (J3).
Vous trouverez ces potentiels changements sur le site eHealth Status.

L’environnement d’acceptation permet de réaliser les tests nécessaires à la mise en place de la release dans l’environnement de production.

Veuillez noter qu'il est indispensable d'utiliser des données (à caractère personnel) fictives lors des processus de tests, l'utilisation de données réelles est strictement interdite.

Il est conseillé de procéder à des tests dans le but, pour chaque release ou à chaque intégration d'un nouveau composant, de vous assurer que vos composants sont compatibles avec les (nouvelles) versions mises en ligne de nos services.
Les Release Notes sont des documents dans lesquels figurent les nouveaux développements principaux, les adaptations des services de base de la plate-forme eHealth, la fin de vie de services et les problèmes éventuels connus.
Les Release Notes sont publiées sur le portail de la plateforme eHealth le jour de la mise en acceptance d’une release.

Intervention de configuration

• Contenu d’une intervention
  • tout changement qui provient
    • d’un projet ( service de base)
    • d’un onboarding
    • d’une demande de support
    • d’un changement de certificat
• Règles à suivre
  • toute modification d'intervention doit être soumise 10 jours avant l'intervention (Freeze date) à notre support via integration-support@ehealth.fgov.be
  • si la modification n'est pas soumise à temps (freeze date), elle est reportée à la prochaine date d'intervention (sauf en cas d'urgence réelle)
• Tableau de configuration

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---