Votre app publiée reste en ligne pendant sa republication

Lorsque vous republiez une app sur Mythex, votre site en ligne continue de servir la version précédente jusqu'à ce que le nouveau build soit prêt, puis bascule. Avant ce changement, une republication mettait le site hors ligne pendant tout le build : les visiteurs voyaient « This published app is offline or the link was not found » pendant une minute environ, puis la même page refonctionnait après un rechargement. Nous avons aussi corrigé deux autres cas où une app en ligne paraissait à tort hors ligne.

1. Republier ne met plus votre site hors ligne

En coulisses, chaque app publiée dispose d'un enregistrement qui indique quel build servir. Une republication réutilisait cet enregistrement et le marquait « building » pendant toute la durée du build, et la partie de notre edge qui achemine les visiteurs ne servait que les enregistrements marqués « live ». Donc chaque republication faisait disparaître le site jusqu'à la fin du build. Nous l'avons reproduit sur une petite app de test : environ 50 secondes hors ligne par republication.

Désormais, lorsqu'une republication démarre sur une app déjà en ligne, l'enregistrement garde la trace d'un build précédent et continue de pointer vers lui. L'edge sert ce build précédent pendant que le nouveau se construit, et le pointeur ne passe au nouveau build que lorsque celui-ci réussit. Si le nouveau build échoue, vos visiteurs ne s'en aperçoivent pas : l'ancienne version reste simplement en ligne.

Une première publication, ou la republication d'une app suspendue ou dépubliée, ne passe en ligne qu'à la fin du build, car il n'existe aucune version précédente à montrer.

2. Un petit incident ne ressemble plus à « introuvable »

Le service placé devant votre app publiée demande à notre API où vit chaque site. Il traitait auparavant toute réponse non réussie, une erreur serveur passagère ou une connexion coupée, comme « ce site n'existe pas », et affichait la page hors ligne. Un rechargement une seconde plus tard fonctionnait, ce qui prêtait à confusion.

Désormais, seule une véritable réponse « introuvable » compte comme introuvable :

• Tout autre échec est réessayé une fois.
• S'il échoue toujours, l'edge sert le site à partir de la dernière réponse valide connue, pendant une heure au maximum.
• Ce n'est que s'il n'a jamais obtenu de réponse qu'il affiche une page « temporairement indisponible », jamais « introuvable ».

Les domaines personnalisés interrogent aussi nos systèmes de production et de préproduction en parallèle, si bien qu'un serveur de préproduction lent ne peut jamais retenir un domaine de production.

3. Une app suspendue le dit

Les apps publiées fonctionnent grâce à votre solde de crédits. S'il tombe à zéro, l'app est suspendue jusqu'à ce que vous rechargiez, puis elle revient toute seule. Mais une app suspendue ressemblait auparavant exactement à une app supprimée.

Désormais, un visiteur d'une app suspendue voit « This app is paused », avec un moyen pour le propriétaire de la réactiver, et la réponse n'est jamais mise en cache : l'app redevient accessible dès qu'elle reprend. Si une app est indisponible pour une autre raison, les visiteurs voient « This app isn't available », sans savoir pourquoi.

Pourquoi c'est important

Une app publiée est quelque chose que vous avez partagé : dans une bio en ligne, sur une carte de visite, auprès de vos premiers clients. Elle doit se comporter comme un vrai site web : rester en ligne pendant que vous l'améliorez, survivre à un petit incident, et être honnête lorsqu'elle est suspendue.

Plus d'informations sur la publication dans la documentation : comment publier et limites d'hébergement. Et le côté infrastructure de la même idée : comment nous avons ramené nos propres déploiements à zéro erreur 502.