Votre app publiée reste maintenant en ligne pendant que vous la republiez

Lorsque vous republiez une app sur Mythex, votre site en ligne continue maintenant 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 toute la durée du build : les visiteurs voyaient « This published app is offline or the link was not found » pendant une minute environ, puis la même page fonctionnait de nouveau après un rechargement. Nous avons aussi corrigé deux autres situations où une app en ligne pouvait à tort paraître hors ligne.

1. Republier ne met plus votre site hors ligne

En coulisses, chaque app publiée possède un enregistrement qui indique quel build servir. Une republication réutilisait cet enregistrement et le marquait « en construction » pendant toute la durée, et la partie de notre périphérie qui achemine les visiteurs ne servait que les enregistrements marqués « en ligne ». Ainsi, 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.

Maintenant, lorsqu'une republication commence sur une app déjà en ligne, l'enregistrement se souvient qu'un build précédent existe et continue de pointer vers lui. La périphérie sert ce build précédent pendant que le nouveau se construit, et le pointeur ne passe au nouveau build qu'en cas de succès. Si le nouveau build échoue, vos visiteurs ne s'en aperçoivent jamais : l'ancienne version reste simplement en ligne.

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

2. Une brève défaillance n'a plus l'air d'un « introuvable »

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

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

• Tout autre échec est retenté une fois.
• S'il échoue encore, la périphérie sert le site à partir de la dernière bonne réponse connue, pendant au plus une heure.
• Ce n'est que si elle n'a jamais eu de réponse qu'elle affiche une page « temporairement indisponible », et jamais « introuvable ».

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

3. Une app en pause le dit

Les apps publiées fonctionnent grâce à votre solde de crédits. Si celui-ci est épuisé, l'app est mise en pause jusqu'à ce que vous rechargiez le solde, et elle redémarre alors d'elle-même. Mais une app en pause ressemblait auparavant exactement à une app supprimée.

Maintenant, un visiteur d'une app en pause voit « This app is paused », avec un moyen de retour pour le propriétaire, et la réponse n'est jamais mise en cache, de sorte que l'app redevient accessible dès qu'elle est reprise. Si une app est indisponible pour une autre raison, les visiteurs voient « This app isn't available », sans qu'on leur dise pourquoi.

Pourquoi c'est important

Une app publiée est quelque chose que vous avez partagé : dans une bio de lien, sur une carte d'affaires, avec vos premiers clients. Elle doit se comporter comme un vrai site Web : rester en ligne pendant que vous l'améliorez, résister à une brève défaillance, et être honnête lorsqu'elle est en pause.

Pour en savoir plus sur la publication, consultez la documentation : comment publier et limites d'hébergement. Et l'aspect infrastructure de la même idée : comment nous avons ramené nos propres déploiements à zéro erreur 502.