Le pipeline de build

Quand vous cliquez sur Build, un processus en arrière-plan transforme la base de données en site statique et, seulement si tout réussit, met les nouveaux fichiers en place. Rien en amont ne montre jamais la moitié d'un build : la première chose qu'un visiteur voit, c'est soit l'ancien site, soit le nouveau en entier.

Comment un build démarre

Les éditions de contenu ne reconstruisent jamais le site d'elles-mêmes. Un build est déclenché depuis le tableau de bord d'administration, l'API, un webhook ou la ligne de commande. Au déclenchement, le système réserve le build pour qu'un seul s'exécute à la fois : cliquer deux fois sur Build ne démarre pas de second build ; le second déclencheur se contente de signaler qu'un build est en cours. Le verrou se libère quand le build se termine (ou échoue), selon ce qui arrive en premier.

Une fois réservé, le builder tourne en arrière-plan avec votre base de données et votre répertoire de sortie qui lui sont explicitement confiés. Selon la manière dont il a été lancé, le build peut être l'exécution incrémentale par défaut, un rebuild complet forcé depuis zéro, ou un build qui contourne les portes de sécurité pour cette seule exécution. À la fin, votre build webhook configuré peut être notifié pour que des systèmes externes apprennent l'événement.

Ce que le builder produit

Le builder fabrique du staging, un répertoire séparé output/.next, pas du live. Le staging reste côte à côte avec le répertoire live jusqu'à la bascule. Cette séparation signifie que toute décision quant à la sécurité d'un build intervient avant que le moindre contenu live ne soit touché, et toutes les décisions de staging sont journalisées avec leur résultat. La sortie live reste intouchée par tout ce qui écrit pendant un build.

Builds incrémentaux et ce qui rend une exécution « complète »

Chaque build démarre en mode incrémental à moins que vous ne le demandiez pas ou que le builder décide que ce n'est pas sûr. Avant de toucher au staging, il parcourt une liste de vérifications d'éligibilité :

• le mode incrémental a été demandé ;
• il existe un horodatage de dernier build, et il n'est pas dans le futur ;
• le répertoire de sortie live existe et contient un index.html ;
• une empreinte de build du précédent build réussi est enregistrée et correspond toujours aux réglages actuels et aux gabarits du thème (une empreinte divergente signifie un « changement global ») ;

Si un contrôle échoue, le build bascule proprement vers un rebuild complet et journalise la raison. Quand la liste passe, le staging est prémonté en liens physiques (hardlinks) depuis le live : les fichiers de contenu ne coûtent de l'espace disque que là où ils changent, et les fichiers inchangés voyagent gratuitement.

Le build ne re-rend ensuite que le contenu modifié (« dirty ») : les éléments mis à jour depuis le dernier build, les éléments dont l'heure de publication ou de dépublication programmée est passée depuis le dernier build, et toutes les pages/billets dépendant de blocs ou de stacks modifiés. Tout le reste est sauté et réutilisé depuis le cache de rendu.

Vitesse de rendu

Le rendu s'exécute par défaut en multi-workers selon le nombre de CPU de la machine (jusqu'à 16), avec un mode séquentiel mono-worker disponible. Tout build reçoit une limite de temps globale, et un budget d'écriture de 2 GiB réparti entre les workers, pour qu'un build récalcitrant ne puisse jamais bloquer le pipeline ni remplir le disque en pleine course.

Passer en live : la bascule du staging

Quand le build se termine avec succès (et que la garde de promotion ne refuse pas de le publier), le staging est déplacé vers le live :

• La disposition de production standard utilise un symlink : la bascule est un unique renommage atomique, zéro interruption.
• Avec une disposition en répertoire : un renommage en deux étapes introduit au plus un bref instant entre les déplacements, sûr sur le même système de fichiers ; le répertoire précédent est conservé pour nettoyage.
• Le tout premier build renomme le staging terminé en live.

Une bascule échouée fait un retour arrière au lieu de publier à moitié, ne laissant jamais un répertoire live cassé.

Quand les choses tournent mal en plein vol

Toute condition fatale, dépassement de délai, dépassement du budget d'écriture, erreurs de rendu, ou échec au moment de la promotion, jette le staging et laisse la sortie précédente servir telle quelle. La signature du manifeste de build a lieu avant la promotion, et si la signature ou la promotion recule, le manifeste précédent est restauré pour qu'une signature hors service ne revendique jamais un contenu qui n'est pas en ligne (cette porte ne peut être relâchée que dans des environnements de test).

Ce que chaque build écrit sur disque

Après chaque passe de langue :

• La sortie qui ne correspond plus au contenu courant (éléments supprimés, dépubliés ou hors fenêtre) est retirée, pour que les URL périmées disparaissent ; que le staging ait été relié par liens physiques au live ou fraîchement rendu, l'ensemble conservé des chemins publiés régit ce qui reste ;
• le sitemap, le flux RSS et la page 404 par langue ;
• les liens internes cassés et les avertissements HTML/a11y, tous consignés.

Le journal de build capture tout cela, les 100 derniers builds avec leur sortie complète et leurs rapports de validation, plus l'horodatage de dernier build qui maintient les exécutions incrémentales éligibles jusqu'au suivant.