En juin, nos apps générées tournaient dans des environnements d’aperçu. Je pouvais examiner un écran pendant que le pipeline le modifiait. C’était utile pendant le développement. Je ne mettrais pas de clients dans ce même environnement.
On s’est attelés à séparer la production de cette boucle d’édition et à donner aux projets une passation vers GitHub.
Dans la note de version d’origine, j’ai décrit certaines parties avec trop d’assurance. Cette révision sépare la conception de ce qu’on peut vérifier au 15 octobre 2026. L’implémentation et la documentation comprennent des chemins pour le déploiement et pour GitHub. Leur seule existence ne vérifie pas chaque déploiement réel, chaque changement de domaine ni chaque retour arrière.
La frontière de la production
Un aperçu se reconstruit au fil de ton travail. La conception place une mise en production délibérée entre cet environnement mouvant et l’app que les gens utilisent. Un déploiement en production devrait servir la version que tu as choisie.
L’hébergement de production est conçu pour utiliser des artefacts déjà construits, sans les outils d’édition de l’aperçu. La configuration et les identifiants de production ont leur propre périmètre. Les utilisateurs finaux de l’app ont aussi besoin de leur propre configuration d’identité, distincte des comptes utilisés pendant le développement.
Stocker un paramètre à part ne prouve pas que chaque chemin du code le traite correctement. Vérifie les valeurs de production, les redirections autorisées et les règles d’accès avant d’envoyer un lien à un client.
Examine l’aperçu, y compris les permissions et les écrans sans données. Configure l’environnement de production, publie, attends que l’app soit prête, puis déroule les parcours importants sur l’app déployée.
Le guide actuel de publication décrit ces étapes, ainsi que les vérifications liées à la capacité de ton offre. Considère une opération réussie dans l’interface comme une étape de la mise en production, puis teste le service qui en résulte.
Le domaine
Le parcours de configuration du domaine relie le nom d’hôte d’une app à un domaine que tu contrôles. Il te faut les enregistrements DNS correspondants, et tu dois vérifier la connexion.
L’article d’origine réduisait tout ça à l’ajout d’un CNAME, après quoi tout marchait. Il passait sous silence l’attente et les vérifications qu’exige un changement de domaine.
Suis les valeurs affichées pour le déploiement. Une fois le DNS résolu, vérifie le nom d’hôte, le certificat et l’application. Revérifie les redirections de connexion sur l’adresse publique. Une URL d’aperçu qui fonctionne ne t’apprend pas grand-chose sur ce dernier point.
On dispose de chemins d’implémentation pour configurer un domaine. Cette réécriture ne fait pas état d’un nouveau test du DNS ou du TLS en conditions réelles.
La passation vers GitHub
Je veux qu’un projet ait une vie utile en dehors de la session qui l’a créé. Un dépôt, c’est l’endroit où l’on relit et où l’on maintient les modifications du code source.
L’intégration GitHub prévoit des chemins pour connecter un compte, publier le code source et échanger des modifications avec un dépôt connecté. Tu peux ensuite examiner le code du projet et ses documents d’accompagnement dans des outils que tu connais.
Publier le code source sur GitHub et publier une app qui tourne sont deux opérations distinctes. Un dépôt ne fait pas tourner de base de données, ne configure pas tes secrets et ne répond pas à un incident de production.
La conception de l’historique repose sur une seule branche principale, des push ordinaires et, pour annuler des modifications, des commits de revert qui font avancer l’historique. On évite de proposer le force-push comme une action normale de la plateforme.
Ça réduit le nombre de cas où notre propre workflow réécrit l’historique, sans permettre pour autant de promettre qu’un utilisateur ne perdra jamais de code. Les permissions du dépôt, les modifications externes et les procédures de récupération comptent toujours.
En octobre, certaines parties de la navigation dans l’historique et du comportement de retour arrière attendent encore des vérifications opérationnelles récentes. Garde ton propre plan de récupération. Ne déduis pas d’un bouton ou d’un chemin d’implémentation qu’une restauration a été testée.
Identifiants et configuration
Telle qu’elle est conçue, l’intégration stocke des identifiants GitHub chiffrés pour chaque projet, en dehors du disque de projet de l’app. L’app ne devrait pas avoir besoin d’un jeton d’accès personnel dans son arborescence source pour que la connexion fonctionne.
Ce choix de stockage n’établit pas que l’ensemble du déploiement a passé un audit de sécurité.
Déplacer un projet ailleurs demande plus que de télécharger son code source. Tu dois fournir la configuration d’exécution, les services de données et les réglages d’identité qu’attend son code. Examine ces dépendances avant de choisir un hébergement.
La documentation sur Git et GitHub explique le workflow du code source. L’article sur l’identité montre pourquoi, pour une application, la connexion n’est qu’une partie du périmètre d’accès.
Le travail de mise en production
Il me faut encore des preuves pour les promesses opérationnelles : un déploiement mené à terme, un domaine qui fonctionne, une récupération éprouvée sur le service réel. Une revue de code ne peut pas fournir ces preuves.
Le travail de juin nous a donné des chemins pour ces tâches. Noter les vérifications qui leur manquent encore est moins gratifiant que de déclarer le problème réglé. C’est aussi plus utile avant que le premier client n’en dépende.
Initialement publié le 16 juin 2026. Révisé le 15 octobre 2026 pour corriger des affirmations trop catégoriques sur le déploiement et la récupération, et pour distinguer les chemins implémentés de la vérification en conditions réelles.