Du code source à une version opérationnelle : ce que fait réellement un déploiement

La première question paraît simple : quels fichiers ce déploiement représente-t-il ? Un répertoire local, une révision Git et un espace de travail ouvert peuvent avoir des contenus différents. Si la plateforme ne peut pas identifier précisément le code qu’elle a compilé, le débogage devient ensuite incertain. Adios enregistre le code source comme artefact afin de relier le déploiement à du code que l’on peut rouvrir dans un espace de travail.

Le paquet doit exclure les fichiers générés jetables tels que node_modules et les répertoires de compilation locale, tout en conservant le fichier de verrouillage, le manifeste et les fichiers nécessaires à la compilation. Un envoi réussi prouve seulement que le paquet est arrivé. Il ne prouve pas que le code compile ni que l’environnement d’exécution peut démarrer.

L’étape de compilation installe les dépendances, exécute la commande déclarée et produit le résultat que le workload lancera. Une compilation échouée doit laisser des journaux et un statut d’échec, sans promouvoir une version incomplète. Adios expose séparément les journaux de compilation et d’exécution, car la résolution des paquets et la compilation ne relèvent pas des mêmes responsabilités que le démarrage de l’application.

Pour une API Go, le résultat de compilation peut être un binaire. Pour Next.js, il comprend le serveur et les ressources. Pour un service Python, l’essentiel peut être d’installer les dépendances aux versions fixées et de préparer l’environnement. La forme varie, mais le principe reste le même : l’environnement d’exécution lance un résultat identifié, issu d’un code source identifié, selon un contrat de compilation explicite.

Une fois la compilation terminée, le worker doit lancer le processus de production déclaré avec son environnement, ses limites de ressources et ses paramètres réseau. Une erreur fréquente est d’écouter sur un port différent de celui du manifeste. Une autre est d’écouter uniquement sur localhost alors que la passerelle doit atteindre le service du workload. Des secrets manquants ou des ressources gérées requises peuvent aussi provoquer un arrêt immédiat du processus ou le laisser actif sans répondre aux requêtes.

Adios crée une version d’exécution avec une ou plusieurs répliques. Le manifeste décrit la région, leur nombre, la commande de démarrage, le port et le chemin de contrôle de santé. Un relecteur peut ainsi évaluer si la nouvelle version peut s’exécuter sans risque, sans dépendre d’un réglage du tableau de bord qui n’a jamais été versionné.

Un processus peut fonctionner alors que ses routes renvoient des erreurs. Le contrôle de préparation vérifie si cette version peut traiter une vraie requête. Un chemin de contrôle de santé utile doit échouer dans un délai limité si une dépendance requise est indisponible, puis se rétablir lorsque celle-ci revient. Il doit éviter les opérations coûteuses qui transformeraient la sonde elle-même en charge.

Le guide de démarrage rapide Adios décrit la promotion après un contrôle de santé réussi du déploiement. La CLI teste aussi un chemin public de contrôle de santé configuré et peut indiquer que la route actuelle fonctionne. Ce sont des observations distinctes : la préparation des répliques protège la version candidate ; une sonde publique vérifie ce qu’un client peut atteindre par le point d’entrée. Une vérification complète nécessite les deux, plus une requête vers une route représentative de l’application.

Une version de déploiement et la version actuellement en service sont deux notions distinctes. Cette distinction permet à un opérateur d’examiner une version échouée ou remplacée sans la confondre avec celle qui sert les utilisateurs. La route doit pointer vers la version qui a réussi les contrôles requis ; si une candidate échoue, la version précédemment en service doit rester disponible.

Le retour arrière prend ici un sens concret : sélectionner une ancienne version connue comme opérationnelle, vérifier ses ressources et sa compatibilité avec le schéma, puis y ramener la route. Une migration de base applicative peut compliquer cette opération même si la plateforme conserve les anciens résultats d’exécution. Examinez la rétrocompatibilité avant de considérer le retour arrière comme automatique.

La requête finale traverse le DNS, TLS, une passerelle d’entrée, la recherche de route et le workload sélectionné. Une panne à l’un de ces points peut donner à l’utilisateur l’impression que le déploiement est cassé, même si le conteneur fonctionne. Interrogez le vrai nom d’hôte et le vrai chemin, vérifiez les redirections et les certificats, puis comparez la réponse avec la version que vous vouliez promouvoir.

Pour un domaine personnalisé, la vérification DNS et l’émission du certificat ajoutent des étapes. Pour une adresse Anycast, le nœud périphérique qui reçoit la requête peut être dans une ville différente du workload. Le test de bon fonctionnement public sert à vérifier tout ce parcours, plutôt qu’à s’arrêter à un contrôle de santé local.

Un déploiement utile produit davantage qu’une URL. Il crée une chaîne reliant le code source, la compilation, la version d’exécution, le résultat de préparation, la version promue et la réponse publique. Lorsque ces identifiants concordent, le développeur sait ce qui est en ligne et comment reprendre après un problème. S’ils divergent, l’étape où les preuves s’arrêtent indique où poursuivre l’enquête.