Si vous avez un nouveau module et que vous devez l'exécuter, setup:upgradeje ne vois pas comment vous pouvez avoir zéro temps d'arrêt. Cela va toujours durer 10 à 20 secondes, car vous devez mettre à niveau la base de données. Ou est-ce que je manque quelque chose?
Même si vous déployez dans un dossier différent et que lorsque tous les fichiers sont générés, vous créez un lien symbolique entre l'environnement en direct et ce dossier, vous devez toujours prendre soin de la base de données.
Réponses:
Je me demande dans quel environnement vous travaillez, où 10 à 20 secondes, voire quelques minutes, de temps d'arrêt seraient un problème. Naturellement, ce n'est pas idéal, mais je dois imaginer que c'est un prix assez modique à payer, surtout si vous vous déployez en dehors des heures de pointe.
Documentation développeur M2: Déployez Magento en production . Au moment de la rédaction de ce document, les documents sont rares et liés à un problème GitHub externe pour discussion. Cependant, ces documents officiels sont un bon endroit pour garder un œil.
Mon équipe étudie l'utilisation de Capistrano pour déployer M2. Nous n'avons pas encore décidé d'un processus final, mais une simple recherche sur Google ("capistrano magento 2") montre qu'un certain nombre de personnes expérimentent avec le même.
Enfin, il existe différents schémas comme le déploiement bleu-vert qui cherchent également à minimiser les temps d'arrêt. Le bleu-vert en particulier, c'est comme avoir un serveur de transfert, mais au moment critique, vous mettez à jour le DNS pour qu'il pointe du bleu au vert, transformant le vert en direct et le bleu en «transfert». Pour le prochain déploiement, le bleu redevient actif. De cette façon, les temps d'arrêt sont théoriquement nuls et les changements se produisent aussi rapidement que le changement DNS se propage.