Publier un site statique avec Pages

Opfield Pages publie un site statique sous forme d’artefact immuable avec un pointeur de promotion explicite. Un Deployment est un ensemble fixe de fichiers ; un tag est un nom déplaçable comme production ; une Route envoie un domaine public vers ce tag. Cette séparation permet à une équipe de revoir une version et de revenir en arrière en déplaçant un pointeur plutôt qu’en modifiant des fichiers sur place.

Pages est destiné à du contenu statique — HTML, JavaScript, CSS, images, polices et autres fichiers servis par nginx. Il ne fournit pas d’environnement d’exécution applicatif côté serveur. Un framework peut être utilisé pendant le build, mais sa sortie doit être un artefact statique adapté au répertoire d’artefact configuré.

Le site vitrine d’Opfield et ce portail de documentation s’exécutent sur Opfield Pages, avec les mêmes Deployments, tags, Routes et retours arrière que ceux décrits ici.

Commencez par la vue d’ensemble de Pages. Pour la livraison Git, préparez les déploiements Git de Pages et une intégration de gestion de sources. Un domaine personnalisé nécessite aussi le chemin domaine, Route et TLS.

Définir le contrat de publication

Avant de créer le projet, décidez :

• quel nœud Ingress ou quel placement détient les fichiers statiques ;
• qui peut téléverser ou construire des Deployments ;
• quel tag représente la production et qui peut le déplacer ;
• quels domaine, certificat et Route publient le tag ;
• si les modifications de source déclenchent des builds automatiques ou un déploiement automatique ;
• quelles valeurs d’exécution visibles côté client sont autorisées ;
• les exigences de conservation des aperçus et des Deployments de retour arrière.

Le projet détient l’historique des déploiements, les tags, la configuration d’exécution, les Routes et le comportement de conservation. Le dépôt source — lorsqu’il est utilisé — détient le code source, mais pas directement la Route publique.

Préparer l’artefact statique

Construisez le site dans un environnement propre et vérifiez que le répertoire de sortie contient les documents d’entrée et toutes les ressources référencées. Testez le routage côté client et les chemins de base avec un serveur statique plutôt qu’avec un serveur de développement. Les serveurs de développement peuvent masquer des fichiers manquants, un rendu réservé au serveur ou des URL de ressources incorrectes.

N’incluez pas de source maps, de jeux de test, de fichiers d’environnement, de métadonnées de dépôts privés, d’identifiants, de topologie interne ou de caches de build, sauf s’ils sont intentionnellement publics. Tout ce qui se trouve dans un artefact Pages doit être considéré comme du contenu public téléchargeable, même si l’interface utilisateur ne pointe pas vers un fichier.

Chemin par artefact manuel

1. Activez Pages dans les paramètres des fonctionnalités et vérifiez que le plan actuel autorise la gestion de Pages.
2. Créez un projet Pages et sélectionnez un nœud Ingress éligible.
3. Configurez les quotas, la conservation et les accès du projet avant de téléverser un artefact de production.
4. Téléversez l’artefact préparé via la Console, l’API de déploiement avec reprise ou le lien de téléversement authentifié du MCP distant. Un artefact peut atteindre la File upload limit, 100 Mo par défaut et 500 Mo au maximum ; voir Vue d’ensemble de Pages.
5. Finalisez le téléversement. Opfield valide et crée un nouveau Deployment immuable au lieu de modifier un Deployment plus ancien.
6. Ouvrez l’aperçu immuable et vérifiez l’artefact exact.
7. Ne déplacez le tag latest géré par le système ou un tag de version personnalisé vers ce Deployment qu’après approbation.
8. Créez ou mettez à jour une Route Pages pour le domaine public et le tag sélectionné.

Un téléversement interrompu n’est pas une publication. Reprenez ou relancez le téléversement via le processus pris en charge et finalisez-le une fois ; ne copiez pas manuellement des fichiers partiels sur un nœud Ingress.

Chemin par build Git

En Business et Enterprise, connectez au projet Pages un dépôt GitLab, GitHub ou Git générique figurant sur la liste d’autorisation. Sélectionnez la branche et la racine de l’application, laissez Opfield détecter package.json le cas échéant, et configurez le gestionnaire de paquets, la version de Node, le script de build et le répertoire de l’artefact.

Le build s’exécute sur un Build Worker isolé. N’ajoutez des Build Secrets limités à la source que pour un accès au moment du build ; ils ne doivent pas se retrouver dans la sortie statique. Examinez le commit exact, les journaux, le résultat des analyses de vulnérabilités et de la politique lorsqu’il est disponible, le worker et l’artefact produit avant publication.

Gardez séparés le build automatique et le déploiement automatique. Le build automatique peut préparer un candidat d’aperçu à chaque événement de source approuvé. Le déploiement automatique déplace un tag et change ce que sert une Route ; ne l’activez que lorsque les protections de branche et les vérifications de recette sont assez solides pour ce risque.

Configuration d’exécution

Pages peut servir une configuration d’exécution visible côté client depuis /_opfield/pages/config.js, sous la forme window.runtime.config. Cette valeur est publique, limitée à 64 Kio et servie avec no-store. Un objet Default s’applique de manière générale, et des remplacements d’objet complet propres à un tag peuvent le remplacer pour un tag routé. Les aperçus immuables utilisent Default.

Utilisez la configuration d’exécution pour des valeurs non secrètes qui varient légitimement selon l’environnement, comme les origines d’API publiques, la présentation des fonctionnalités ou les identifiants d’analytics. N’y placez jamais de mots de passe, de clés d’API, de points de terminaison privés, de matériel de signature, de données réservées aux clients ou de topologie réseau.

Modifier la configuration d’exécution ne crée pas de nouveau Deployment et ne change pas l’empreinte de l’artefact. Gardez la configuration rétrocompatible tant qu’un tag peut passer d’une ancienne à une nouvelle version.

Publier le domaine

Créez ou sélectionnez le domaine et le certificat, puis créez une Route Pages ciblant le projet et le tag choisis. Les Routes ciblent des tags, pas des Deployments bruts. La promotion et le retour arrière restent ainsi explicites et enregistrés.

Vérifiez le DNS, TLS, le document d’entrée renvoyé, les ressources imbriquées, la navigation côté client, le comportement du cache, window.runtime.config et les pages d’erreur. Testez depuis une session de navigateur propre et un réseau externe. Un aperçu immuable prouve l’artefact ; la Route publique prouve en plus le DNS, TLS, la sélection du tag et la matérialisation sur l’ingress.

Critères de réussite

• Le Deployment Pages est Ready et dispose d’un aperçu immuable.
• Le tag prévu pointe vers le Deployment revu.
• La Route publique sert ce tag via un TLS de confiance.
• Les ressources statiques et les routes côté client fonctionnent depuis des URL d’entrée directes.
• Aucun secret ni fichier réservé à l’usage interne n’est présent dans l’artefact ou la configuration d’exécution.
• L’enregistrement du commit ou du build du déploiement est visible lorsque la livraison Git est utilisée.
• Un Deployment précédent réputé sain reste disponible pour le retour arrière.

Retour arrière et nettoyage

Pour revenir en arrière, déplacez le tag public vers le Deployment vérifié précédent. Testez ensuite à nouveau la Route, les ressources, la configuration d’exécution et le comportement du navigateur. Ne modifiez pas et ne remplacez pas sur place le Deployment défaillant ; son enregistrement immuable est utile au diagnostic et prouve ce qui a réellement été publié.

Supprimer un Deployment peut supprimer une cible de retour arrière. Examinez d’abord les références des tags et les exigences de conservation. Supprimer un tag ou une Route modifie la joignabilité, mais n’altère pas l’artefact immuable. Ne désactivez Pages globalement que sur décision produit explicite ; désactiver la navigation ne remplace pas la mise hors service des Routes publiques ni la conservation des éléments de preuve requis.

Carte de diagnostic

Symptôme	À vérifier d’abord	Guide détaillé
Le téléversement a été interrompu	État du téléversement et tâche ; ne copiez pas manuellement des fichiers partiels	Tâches, événements et audit
Le build Git a échoué	Paramètres de source, Build Worker, journaux et décision de la politique	Déploiements Git de Pages
L’aperçu fonctionne mais la Route publique échoue	Tag, domaine, DNS, TLS et placement sur l’ingress	Dépannage de l’ingress
Une URL directe renvoie 404	Document d’entrée, chemin de base et routage côté client	Déploiements Git de Pages
La configuration d’exécution est incorrecte	Default, remplacement d’objet complet par tag et compatibilité des versions	Vue d’ensemble de Pages
Il ne reste aucune cible de retour arrière	Références des tags et conservation des Deployments	Vue d’ensemble de Pages