Rollback OpenShip : checklist de production

La console affiche « rollback réussi », mais l’ancien code ne peut pas lire la nouvelle base de données.

La solution la plus rapide consiste à refuser le déploiement tant que cinq preuves ne sont pas réunies : ancien artefact démarrable, configuration restaurable, migration compatible, trafic effectivement basculé et tâches d’arrière-plan protégées contre les doublons.

Cette checklist s’adresse aux équipes qui préparent OpenShip pour une production de SaaS IA, un service d’administration ou une API d’agent. Elle concerne aussi les responsables de publication qui doivent documenter une décision d’approbation, ainsi que les développeurs qui exploitent une base de données, des Workers, des files de messages ou des connexions WebSocket.

Le vrai résultat attendu

Un rollback ne doit pas être déclaré réussi parce que le tableau de bord affiche une ancienne version. Pour votre équipe, il faut distinguer trois niveaux :

Succès de contrôle : OpenShip accepte l’action et associe le service à une version antérieure.
Succès d’exécution : l’artefact précédent démarre, reste sain et reçoit des connexions.
Succès métier : les utilisateurs retrouvent les fonctions essentielles, les données restent cohérentes et les traitements ne produisent pas d’effets secondaires indésirables.

La plateforme présente les déploiements comme des instantanés immuables, avec conservation des versions précédentes, vérifications de santé et retour vers une version antérieure. Ce sont des capacités annoncées par OpenShip ; elles ne constituent pas, à elles seules, une preuve de restauration de votre application complète. Présentation officielle du déploiement et des rollbacks OpenShip

Avant toute publication, écrivez donc votre critère d’acceptation dans le ticket de livraison :

quelles routes doivent répondre ;
quelle opération d’écriture doit rester possible ;
quelles données doivent être conservées ;
quelle dégradation est acceptable ;
qui autorise le rollback ;
qui prend en charge une éventuelle restauration des données.

Ne promettez pas un délai de récupération ou une absence d’interruption sans mesure issue de votre propre projet. Le résultat dépend de la taille des images, des connexions persistantes, du nombre de services, de la base de données et de la méthode de bascule.

Artefacts et dépendances d’exécution

Le premier test consiste à prouver que l’ancienne version existe encore sous une forme exploitable. Un identifiant Git ne suffit pas si votre pipeline reconstruit l’image avec des dépendances flottantes ou si le registre ne conserve plus l’image correspondante.

Pour la version cible, enregistrez :

l’identifiant du déploiement ;
le condensat de l’image ou de l’artefact ;
la version des dépendances ;
la commande de démarrage ;
le port d’écoute ;
la date de création ;
les journaux du déploiement initial.

OpenShip indique que les images sont construites puis identifiées comme des artefacts versionnés, avant d’être démarrées dans un nouveau conteneur. La vérification utile n’est pas la déclaration marketing : c’est le redémarrage réel d’un nouvel exemplaire à partir de cet artefact. Description officielle du chemin de déploiement

Test à exécuter : démarrez l’ancienne version dans un environnement isolé, sans réutiliser le conteneur qui sert encore en production. Lancez ensuite une seconde instance après suppression du cache local et vérifiez que l’image, les dépendances et la commande de démarrage restent accessibles.

Preuve à conserver : identifiant d’artefact, journaux de démarrage, sortie de la sonde de santé et résultat d’une requête fonctionnelle.

Critère de passage : l’instance démarre depuis l’artefact conservé et répond sans fichier ou volume temporaire provenant de la nouvelle version.

Action en cas d’échec : interdisez le rollback automatique, reconstruisez un artefact immuable ou prolongez la conservation de la version validée. Ne considérez pas une nouvelle compilation comme équivalente à l’ancien binaire.

L’environnement de contrôle doit aussi être suffisamment stable pour effectuer ce test. La documentation d’installation indique un minimum de 2 cœurs, 2 Go de mémoire et 20 Go de disque pour une installation auto-hébergée ; ces valeurs concernent le fonctionnement de la plateforme, pas la capacité réelle de votre application. Prérequis officiels d’installation

Configuration, secrets et services externes

OpenShip restaure-t-il automatiquement les anciennes variables d’environnement ? Vous ne devez pas répondre oui sans comparer la configuration effective du conteneur restauré avec celle de la version cible.

Un rollback de code peut échouer de manière silencieuse si :

l’ancien code reçoit une variable ajoutée uniquement pour la nouvelle version ;
une URL d’API pointe encore vers un service incompatible ;
une clé possède désormais des permissions différentes ;
le nom d’une file ou d’un compartiment de stockage a changé ;
le secret a été renouvelé sans conserver une version utilisable par l’ancienne application.

La page officielle présente un coffre de secrets chiffrés, organisé par environnement, ainsi que la possibilité de faire tourner les secrets sans redéployer. Cela décrit une fonction de gestion de configuration ; vous devez encore vérifier quelle version est effectivement injectée lors du rollback. Fonctions officielles de gestion des secrets et de l’audit

Conservez uniquement des métadonnées non sensibles :

nom de la variable ;
version de configuration ;
condensat de la valeur ;
date de rotation ;
service auquel elle est destinée ;
résultat du test de permission.

Ne copiez jamais une clé réelle dans un ticket, une capture d’écran ou un exemple de procédure.

Test à exécuter : comparez la configuration déclarée avant et après le rollback, puis appelez chaque service externe critique avec une opération sans effet destructeur.

Critère de passage : l’ancien code utilise les endpoints, certificats et permissions attendus ; aucune valeur de configuration ne renvoie par erreur vers le service réservé à la nouvelle version.

Action en cas d’échec : bloquez la bascule, restaurez la version de configuration compatible ou déployez une couche d’adaptation. Le fait que le conteneur soit « sain » ne prouve pas que les intégrations métier le sont.

Base de données et migrations

Une base déjà migrée empêche-t-elle tout rollback OpenShip de l’application ? Non, mais la réponse dépend de la migration. Il faut séparer trois cas :

migration réversible : le schéma peut être ramené à l’état précédent avec une procédure testée ;
migration rétrocompatible : l’ancien code lit le nouveau schéma pendant une période de transition ;
migration destructive : une colonne, un index, un format ou une donnée nécessaire à l’ancien code a été supprimé ou transformé.

Dans le troisième cas, le retour de l’image ne restaure pas automatiquement la base. OpenShip peut remettre l’ancien processus en service ; cela ne signifie pas que PostgreSQL, MySQL, MongoDB ou une autre base revient à son état antérieur. La documentation officielle distingue d’ailleurs les services de données, les sauvegardes et les déploiements applicatifs. Services de données et sauvegardes annoncés par OpenShip

Le test doit être réalisé sur une copie représentative :

exportez la version du schéma avant la publication ;
appliquez la migration de la nouvelle version ;
démarrez l’ancien artefact contre ce schéma ;
exécutez les lectures et écritures critiques ;
vérifiez les contraintes, les relations et les données sérialisées ;
testez séparément la restauration depuis une sauvegarde.

La preuve attendue n’est pas simplement « la migration s’est terminée ». Il faut montrer que l’ancien code peut lire les lignes existantes et produire une écriture valide.

Attention : une sauvegarde disponible n’est pas une sauvegarde restaurable. Sans restauration complète sur une base isolée, vous ne disposez pas encore d’une preuve de reprise des données.

Le tableau suivant vous aide à décider du traitement à appliquer :

Type de changement	Ancien code après migration	Rollback applicatif	Action obligatoire
Ajout d’une colonne facultative	Généralement compatible	Possible sous réserve de test	Vérifier les lectures et écritures
Renommage avec couche de compatibilité	Compatible pendant la transition	Possible	Conserver l’ancien nom jusqu’à la fin de la transition
Suppression d’une colonne utilisée	Incompatible	Insuffisant	Restaurer les données ou appliquer une migration inverse
Changement de format sérialisé	À vérifier	Risqué	Tester les anciennes données et prévoir une conversion
Suppression définitive de données	Non récupérable par le code seul	Impossible seul	Utiliser une sauvegarde indépendante

Ne confondez donc jamais rollback de l’application et restauration de la base. Pour approfondir cette séparation, vous pouvez consulter notre guide sur la location d’un Mac pour un environnement de validation isolé, utile lorsque le poste de construction local ne doit pas être interrompu pendant les essais.

Santé, trafic et connexions persistantes

La sonde de santé doit être conçue pour empêcher une instance incomplète de recevoir du trafic. Un code HTTP positif sur /health ne suffit pas si l’API ne peut plus accéder à la base, si le modèle d’agent n’est pas chargé ou si le service de streaming ferme immédiatement les connexions.

Testez au minimum :

une requête HTTP ordinaire ;
une opération d’authentification ;
une lecture et une écriture métier ;
une réponse en flux ;
une connexion WebSocket si votre Agent API l’utilise ;
un appel vers chaque dépendance critique.

OpenShip annonce des contrôles de santé, du routage pondéré, des sessions persistantes et la prise en charge des WebSocket. Ces fonctions doivent être confrontées à votre trafic réel, notamment pour l’audio, la vidéo, les interfaces de conception collaborative ou les agents qui maintiennent une session longue. Capacités officielles de routage et de connexions persistantes

OpenShip peut-il éviter toute interruption pendant le rollback ? Il peut organiser une bascule progressive ou sans arrêt selon l’architecture annoncée, mais vous ne pouvez valider « zéro interruption » qu’après un test avec vos propres connexions.

Mesurez avant et après la bascule :

les codes d’erreur ;
les délais de réponse ;
les réponses interrompues ;
les reconnexions WebSocket ;
les requêtes arrivées sur l’ancienne instance ;
les journaux de routage ;
les erreurs côté navigateur ou client SDK.

Le passage est accepté lorsque les routes critiques répondent sur la version restaurée et que les connexions longues suivent une règle définie : maintien, reconnexion contrôlée ou fermeture explicite avec reprise côté client.

Tâches en arrière-plan et idempotence

Le rollback devient dangereux lorsque l’application exécute des tâches qui produisent des effets externes : facturation, envoi de courriels, génération de fichiers audio, indexation, appel d’outil ou mise à jour d’un CRM.

OpenShip présente des tâches planifiées avec reprises, visibilité et journaux par exécution. Cela vous donne des points d’observation, mais la déduplication doit rester une propriété de votre application. Fonctionnalités officielles relatives aux tâches planifiées

Pourquoi une tâche peut-elle être exécutée deux fois après un rollback ? Parce que l’ancien Worker et le nouveau Worker peuvent avoir vu le même message à des moments différents, parce qu’un accusé de réception a été perdu ou parce qu’une relance automatique ne sait pas distinguer une exécution terminée d’une exécution interrompue.

Vérifiez, pour chaque tâche :

un identifiant unique ;
un état durable : créée, en cours, terminée, échouée ;
une clé d’idempotence ;
une trace de l’effet externe ;
une stratégie de verrouillage ;
une action de compensation.

Le test doit provoquer une interruption pendant l’exécution, puis simuler le retour à l’ancienne version. Vous devez pouvoir répondre à trois questions : la tâche est-elle relancée, l’effet externe est-il répété, et comment l’équipe arrête-t-elle la file si les doublons apparaissent ?

Si un doublon est détecté, suspendez les consommateurs concernés, identifiez les tâches par leur identifiant, empêchez la répétition de l’effet, puis appliquez une compensation documentée. Ne supprimez pas simplement la file : vous risqueriez de perdre les tâches légitimes.

Checklist d’acceptation avant production

Utilisez cette liste comme pièce jointe du ticket de publication :

[ ] La version cible du rollback possède un identifiant d’artefact immuable.
[ ] Un nouveau conteneur démarre sans dépendre d’un volume résiduel.
[ ] La commande de démarrage et les dépendances sont encore disponibles.
[ ] Les variables d’environnement effectives ont été comparées.
[ ] Les secrets sont vérifiés par version, condensat ou date de rotation uniquement.
[ ] Les permissions vers les API externes ont été testées.
[ ] La migration a été classée comme réversible, rétrocompatible ou destructive.
[ ] L’ancien code a été testé contre le schéma réellement obtenu après migration.
[ ] Une restauration indépendante de la sauvegarde a été réalisée si nécessaire.
[ ] Les routes HTTP critiques répondent après la bascule.
[ ] Le flux de réponse et les WebSocket ont été testés avec des clients réels.
[ ] Les journaux avant et après le changement sont conservés.
[ ] Les Workers, cron et files de messages ont été arrêtés, contrôlés ou rendus idempotents.
[ ] Les tâches doublonnées disposent d’une procédure d’arrêt et de compensation.
[ ] Le responsable du rollback et le responsable des données sont nommés.
[ ] Le déclencheur d’abandon est écrit dans le dossier de livraison.
[ ] La conclusion est classée : passage, mise en ligne limitée ou interdiction.

Décision de publication

À la fin de l’exercice, ne choisissez pas uniquement entre « réussi » et « échoué ». Utilisez trois décisions opérationnelles.

Passage : l’ancien artefact démarre, la configuration correspond, la base reste compatible, le trafic revient sur les routes attendues et les tâches ne répètent pas leurs effets.

Mise en ligne limitée : le rollback applicatif fonctionne, mais une fonction secondaire — par exemple un Worker, une route WebSocket ou une migration non critique — reste sous surveillance. Dans ce cas, réduisez le périmètre d’utilisateurs et inscrivez une date de résolution.

Interdiction : une migration destructive n’a pas de procédure de restauration, l’artefact est introuvable, la configuration pointe vers un service incompatible ou les traitements asynchrones peuvent créer des doublons non maîtrisés.

Pour automatiser l’approbation, vous pouvez également examiner l’API officielle d’OpenShip afin d’archiver l’identifiant, l’état et l’URL de chaque déploiement dans votre propre registre de livraison. Référence officielle de l’API OpenShip

Quand une autre stratégie est préférable

OpenShip est intéressant si vous voulez conserver des versions applicatives, relancer rapidement un service et centraliser les journaux, le routage et les déploiements. En revanche, le rollback reste incomplet si votre équipe ne maîtrise pas les migrations, les secrets ou les effets des Workers.

Une stratégie locale peut sembler plus simple, mais elle dépend souvent d’un poste de construction qui n’est pas disponible en permanence, d’un environnement difficile à reproduire et d’un test de reprise reporté au dernier moment. Pour une validation ponctuelle, un Mac loué peut fournir un environnement séparé pour reconstruire, tester les flux audio ou vidéo et exécuter une répétition complète sans immobiliser le poste principal. Vous pouvez comparer les options de Mac mini loué pour les équipes de développement avant de choisir.

La meilleure décision n’est donc pas de croire que le bouton de rollback répare tout. C’est de faire une répétition complète avant la première mise en production, avec l’application, la configuration, la base, le trafic et les tâches traités comme cinq éléments distincts. Si votre équipe ne dispose pas d’une machine de construction toujours accessible ou d’un environnement isolé pour cette répétition, Kvmzen peut servir de solution temporaire de validation plutôt que de remplacer une architecture de reprise correctement conçue.