Rendez votre prochain déploiement reproductible

Rassembler des entrées identifiables

Utilisez une application que vous pouvez construire dans un environnement non-production, l'accès au code source et à son registre d'artefacts, un schéma de configuration versionné et un magasin de secrets externe. Conservez une version fonctionnelle connue. Ce sont des entrées pour votre automatisation ; PrivacyNodes ne fournit pas d'API de déploiement ni d'exécuteur de pipeline via ce site web.

Épinglez l'artefact au lieu de vous fier à une étiquette mutable telle que latest. Docker documente l'épinglage par digest pour identifier une image de base exacte, avec la nécessité de revoir les mises à jour délibérément. La reproductibilité et le correctif sont deux responsabilités : conserver indéfiniment une ancienne image vulnérable n'est pas un plan de maintenance.

Référence technique : Bonnes pratiques de build Docker.

Rédiger un registre de version avant de modifier le trafic

Ceci est un format de document, pas un script exécutable. Remplissez les espaces réservés à partir de l'artefact révisé. Une révision de source seule ne décrit pas les changements d'environnement. Incluez la durée de migration observée, le comportement de verrouillage attendu, les différences de configuration et le dernier artefact fonctionnel.

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

Stockez le registre dans un endroit accessible lorsque l'application est arrêtée. Référencez les identifiants de récupération protégés sans inclure leurs valeurs. Nommez le mainteneur qui peut arrêter la promotion et le point après lequel la restauration planifiée n'est plus valide.

Séparer la préparation de la promotion

Construisez et inspectez d'abord l'artefact. Validez la configuration et les références de secrets avant de démarrer le nouveau processus. Appliquez uniquement l'étape de schéma revue pour cette version. Démarrez la nouvelle version dans l'environnement prévu et vérifiez les dépendances avant de déplacer le trafic ; évitez de combiner une migration destructive non revue avec une simple mise à jour d'image.

Avec Compose, un conteneur démarré n'établit pas l'état prêt. Un contrôle de santé significatif et condition: service_healthy peuvent rendre l'attente des dépendances utile, mais ne peuvent pas vérifier un flux de travail client. L'application doit encore gérer l'indisponibilité d'une dépendance après le démarrage.

Référence technique : Ordre de démarrage de Docker Compose.

Vérifier plus qu'un port vert

Pour l'API de reporting, vérifiez une requête de test authentifiée, une lecture sur le schéma prévu, un petit export en file d'attente et l'accès à son fichier. Utilisez un espace de noms de test dédié et supprimez les notifications de production. Vérifiez que des versions qui se chevauchent ne peuvent pas dupliquer accidentellement le travail planifié.

Rédigez les sorties attendues avant la vérification : périmètre de compte correct, enregistrement d'exemple attendu, un export terminé et aucune donnée inter-comptes non autorisée. Consignez les sorties réelles et le minutage par la suite. Une page d'accueil renvoyant HTTP 200 est insuffisante si un worker échoue de façon répétée ou si une migration a laissé l'API lire des valeurs obsolètes.

Rendre explicite la décision de récupération

Si le processus ne démarre pas, maintenez le trafic sur la version qui fonctionne. Si une vérification de workflow échoue, arrêtez la promotion et conservez des preuves expurgées. Un schéma additif compatible avec l'ancien artefact peut permettre un retour arrière de l'application. Après une transformation incompatible, l'ancien code peut être dangereux ; suivez le plan de correction en avant ou de récupération de données qui a été revu.

Ne répétez pas indéfiniment une migration qui échoue. Déterminez ce qui a été validé, si une nouvelle tentative est sûre et si des utilisateurs ont écrit sous le nouveau schéma. Le guide de migration développe cette limite avec un changement de colonne. Ne considérez pas l'existence d'un bouton de retour arrière comme la preuve que les données peuvent être rétablies.

Laisser un registre qu'un autre mainteneur peut suivre

Comparez les identifiants de l'artefact déployé et de la configuration avec l'enregistrement prévu. Conservez les vérifications, les tentatives échouées et l'action de récupération choisie. Gardez le dernier artefact fonctionnel sous une politique de rétention explicite ; ne le supprimez pas tant que la validation est incomplète.

Une répétition utile permet à un autre mainteneur autorisé d'expliquer les entrées, de refaire les vérifications et de trouver les instructions de récupération sans fouiller votre historique de shell. Elle ne prouve ni une absence d'interruption ni une réussite future. Revenez-y lorsque le schéma, le comportement des workers ou les dépendances changent. Ensuite, restreignez les autorisations de l'identité de déploiement.