Opérations et gestion → Cycles de publication et de mise à jour

Cycles de publication et de mise à jour

1) Destination

• réduit l'incertitude et le coût de la coordination,
• réduit le risque d'incidents et de reculs,
• synchronise la technique avec les événements commerciaux (marketing, sport, fin. rapports),
• augmente les commandes throughput sans croissance CFR (Change Failure Rate).

2) Modèles de sortie : lequel choisir

1. Release Train (trains) - slots fixes (par exemple, w/cht 10:00 EET).

Convient pour les monolithes multi-commandes et les changements de domaine « lourds ».

2. Continuous Delivery (sur demande) - chaque merge qui a passé les gates de qualité peut aller à la prod.

Convient pour les microservices et la culture feature-flag.

3. L'hybride est un front de produits par train, des services de backend « sur demande ».

Critères de sélection : maturité des tests/observabilité, dépendance à l'égard des partenaires externes (PSP/KYC), exigences de conformité, taille de l'organisation.

3) Calendrier de sortie et fenêtres

Calendrier unique : slots de sortie, migration OBD, campagnes marketing, événements sportifs majeurs, périodes de déclaration.
Périodes Freeze : fenêtres clairement définies lorsque seuls les hotfix P1 sont autorisés (par exemple finale LH, Black Friday, déclaration fiscale).
Vagues régionales : d'abord marchés « chauds »/faible trafic, puis principaux ; fenêtres de nuit des TZ locaux.
Politique de croisement : interdire les modifications simultanées sur un chemin critique (paiements, KYC, autorisation).

4) Branchement et versioning

Trunk-based + short-lived branches (branche fonctionnelle ≤ 3-5 jours).
Release-branche - uniquement pour les trains/longues vérifications ; dur back-merge en 'main'.
SemVer: `MAJOR. MINOR. PATCH'pour les bibliothèques/SDK ; étiquettes d'artefacts et d'environnements.
Contrats : schémas (Avro/Protobuf) avec compatibilité back/forward ; les migrations sont biphasées.

5) Canveers de qualité (gates)

1. Statique + SAST/DAST + linters

2. Tests d'unité/contrat/composant

3. E2E/Performance smoke (sur le steadge)

4. Security/Compliance checks (secrets, licences, politique des territoires)

5. Libération Candidate → signature, SBOM, artefacts

6. Rollout progressif avec auto-garderies (voir § 7)

Tous les gates sont le code et la politique (Policy-as-Code), les résultats sont dans les artefacts de sortie.

6) Environnements et promotions

Dev → Int → Stage → Prod, pour les données : Sandbox/Data-Stage.
GitOps promotions, images immuables, interdiction des modifications « manuelles » dans la vente.
Paramétrage : régions, limites, fournisseurs - via configi (vérifiable).

7) Stratégies de déroulement

Canary: 1%→5%→25%→100% (или per-region).
Bleu-Vert : environnements parallèles + commutation atomique.
Feature Flags : inclusions fonctionnelles/kill-switch ; A/B и shadow.
Staged Rollout Mobile/Web : selon les versions client/canaux de livraison (Store/OTA).

Gardrails (arrêt automatique) : p95 latency ↑> 25 %, error %> 2 %, baisse des autorisations/dépôts, augmentation des chargbacks, burn-rate SLO pour 1 heure fenêtre> seuil.

8) Accord avec les entreprises et les partenaires

Marketing/Evénements : Lancement de la fonctionnalité aux campagnes avec une réserve de 48 heures ≥

Partenaires (PSP/KYC/Game providers) : slots de certification/mises à jour SDK, doubles endpoints pour la période de migration.
Support : macros/FAQ pour les changements UX, pages d'état, canaux d'escalade.

9) Mises à jour des données et des schémas

Additive first : d'abord ajouter, puis changer de lecture/écriture, à la fin - supprimer l'ancien.
Les indices et les grandes migrations sont des fenêtres de nuit, des patates, des chekpoints et des progrès.
Versioning vitrines et dictionnaire de métriques : mises à jour synchronisées avec la version, migration BI - séparées des fenêtres de vente.

10) Communications et artefacts

Release Notes (quoi/pourquoi/risques/rollback), ChangeLog par service.
Invites de calendrier pour les stackholders, modèles d'annonces (avant/pendant/après).

War-room canal pendant les trains/grandes sorties, fréquence des updates : P1 - toutes les 15-20 minutes

11) Métriques d'efficacité

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
Backout Rate par type de changement.
SLO Conformité % avant/après les sorties.
Release Debt : drapeaux « suspendus », migrations inachevées, anciennes dépendances.
Business Impact : conversion, KYC TTV, PSP success, GGR/NGR drift dans la fenêtre de sortie.

12) Anti-modèles

Big-bang : « tout le monde et à la fois » sans drapeaux/canaries.
Sortie au sommet du trafic/des événements sans exceptions freeze.
Sans auto-gardrail : surveillance manuelle « à l'œil ».
Branches à longue durée de vie : amalgames douloureuses et régressions latentes.
Étapes manuelles dans la vente : pas d'audit et de prévisibilité.
Drapeaux sans TTL et propriétaires : branches « éternelles ».

13) Chèques-feuilles

Avant la sortie

• RFC/ticket, risque et blast-radius évalués
• Les gates CI/CD sont passées, les artefacts sont signés
• Plan de roulement + critères stop + backout prêt
• Alignement avec calendrier, freeze et partenaires
• Dashboards/alerties liés à la version, war-room créé

Pendant la sortie

• Les étapes canaries et auto-stop sont actives
• Métriques p95/error %, signaux d'affaires (auth, KYC, PSP) sur le moniteur
• Communications programmées, mise à jour de la page de statut

Après la sortie

• Release Notes et ChangeLog publiés
• Drapeaux supprimés/exceptions temporaires (TTL)
• Le post-mortem en cas de déviation ≤ 5 esclaves. jours
• Mise à jour des pleybooks et de la documentation

14) Mini-modèles

• Date/heure : W, 10 : 00-12 : 00 EET
• Comté : EU (10%→50%→100 %), puis LATAM (10%→100 %)
• Critères d'arrêt : error %> 2 % 10 min, p95> + 25 % 10 min, PSP success <97 %
• Backout : basculement du trafic vers la version précédente + retour des drapeaux
• Contact : @ RelEng, @ SRE-on-call, @ Support

• Quoi de neuf/Pourquoi
• Impact sur les utilisateurs et les partenaires
• Risques et contraintes connues
• Plan de déroulement/Critères d'arrêt/Backout
• Métriques pour la surveillance
• Contacts et canaux de soutien

15) Intégration avec les disciplines voisines

Gestion du changement : classification standard/normal/emergency, ACR, audit.
Réduire les conséquences des incidents : drapeaux de ficha prêts, quotas, shedding.
Audit des configurations : toutes les promotions via Git, drift-detect et journal des applications.
Politiques d'exécution : Limites/Délais/Retrai - comme un code, avec contrainte.

16) Résultat

Les cycles de sortie sont un rythme contrôlé entre la vitesse et la fiabilité. Fentes fixes là où la coordination est nécessaire ; « sur demande » lorsque la maturité de l'automatisation. Partout - un calendrier, des drapeaux et des canaries, des gardes automatiques et des communications transparentes. C'est ainsi que les sorties deviennent prévisibles, sûres et économiques.