Bonnes pratiques de déploiement
Les scripts de build et de déploiement s’activent lorsque vous fusionnez du code dans un environnement distant. Ces scripts utilisent l’environnement fichiers de configuration et le code de l’application pour fournir à l’infrastructure cloud les données et services appropriés. En outre, ces scripts sont utilisés pour installer ou mettre à jour l’application Adobe Commerce, des services tiers et des extensions personnalisées dans l’environnement cloud.
Le processus de création et de déploiement est légèrement différent pour chaque plan :
-
Plans de démarrage : pour l’environnement d’intégration, chaque branche active crée et déploie un environnement complet pour l’accès et les tests. Testez entièrement votre code après sa fusion dans la branche
staging
. Pour lancer votre site, envoyez desstaging
àmaster
pour le déployer dans l’environnement de production. Vous disposez d’un accès complet à toutes les branches via les commandes Cloud Console et CLI. -
Plans Pro : pour l’environnement d’intégration, chaque branche active crée et déploie un environnement complet pour l’accès et les tests. Fusionnez votre code dans la branche
integration
avant de le fusionner dans les environnements d’évaluation et de production. Vous pouvez fusionner dans les environnements d’évaluation et de production à l’aide de l’Cloud Console ou des commandes SSH etmagento-cloud
de l’interface de ligne de commande.
Suivre le processus
Vous pouvez effectuer le suivi des actions de génération et de déploiement en temps réel à l’aide du terminal ou des messages de statut de Cloud Console (in-progress
, pending
, success
ou failed
) affichés pendant le processus de déploiement. Vous pouvez afficher les détails dans les fichiers journaux. Voir Afficher les journaux.
Si vous utilisez des référentiels GitHub externes, le journal des opérations ne s’affiche pas dans la session GitHub. Cependant, vous pouvez toujours suivre l’activité dans l’interface pour le référentiel externe et le Cloud Console. Pour plus d'informations, consultez la section Intégrations.
Vous pouvez activer le suivi des déploiements avec New Relic pour surveiller les événements de déploiement et analyser les performances entre les déploiements.
Bonnes pratiques relatives aux builds et au déploiement
Examinez ces bonnes pratiques et considérations concernant votre processus de déploiement :
-
Assurez-vous d’exécuter la version la plus récente du package
ece-tools
-
Suivez le processus de création et de déploiement
Assurez-vous que vous disposez du code correct dans chaque environnement afin d’éviter de remplacer des configurations lors de la fusion de code entre des environnements. Par exemple, pour appliquer des modifications de configuration à tous les environnements, modifiez et testez les modifications dans l’environnement local avant de procéder au déploiement dans l’environnement d’intégration distant. Ensuite, déployez et testez les modifications dans l’environnement d’évaluation avant de procéder au déploiement en production. Lorsque vous fusionnez d’un environnement à un autre, le déploiement remplace tout le code de l’environnement, à l’exception de la configuration et des paramètres spécifiques à l’environnement.
-
Utiliser les mêmes variables dans les environnements
Les valeurs de ces variables peuvent différer d’un environnement à l’autre. Cependant, vous avez généralement besoin des mêmes variables dans chaque environnement. Voir Gestion de la configuration pour les paramètres de magasin.
-
Conserver les valeurs de configuration et les données sensibles dans des variables spécifiques à un environnement
Ces valeurs incluent les variables spécifiées à l’aide de l’interface de ligne de commande Cloud, du Cloud Console ou ajoutées au fichier
env.php
. Voir Niveaux de variable. -
Vérifiez que tout le code est disponible dans la branche d’environnement
Le référencement de code d’autres branches, telles qu’une branche privée, peut entraîner des problèmes au cours du processus de création et de déploiement. Par exemple, si vous référencez un thème à partir d’une branche privée, il n’est pas accessible et ne peut pas être créé avec le code de l’application.
-
Ajouter des extensions, des intégrations et du code dans des branches itérées
Apportez et testez les modifications localement, appuyez sur
integration
, puis surstaging
etproduction
. Testez et résolvez les problèmes dans chaque environnement avant de fusionner les mises à jour dans l’environnement suivant. Certaines extensions et intégrations doivent être activées et configurées dans un ordre spécifique en raison des dépendances. L’ajout et le test de groupes peuvent faciliter considérablement votre processus de création et de déploiement et vous aider à déterminer où les problèmes se produisent. -
Vérifier les versions et les relations des services et la possibilité de se connecter
Vérifiez les services disponibles pour votre application et assurez-vous que vous utilisez la version la plus récente et compatible. Voir Relations de service et Configuration requise dans le Guide d’installation pour obtenir les versions recommandées.
-
Testez localement et dans l’environnement d’intégration avant le déploiement dans les environnements d’évaluation et de production
Identifiez et corrigez les problèmes dans vos environnements locaux et d’intégration afin d’éviter les interruptions de service prolongées lors du déploiement dans les environnements d’évaluation et de production.
note tip TIP Vous pouvez utiliser des commandes assistant intelligent pour vérifier que la configuration de votre projet cloud suit les bonnes pratiques de création et de configuration de déploiement, y compris la stratégie de déploiement de contenu statique (SCD). -
Après avoir effectué les tests dans les environnements locaux et d’intégration, déployez et testez-les dans l’environnement d’évaluation
-
Vérifiez la configuration de l’environnement de production
Avant le déploiement en production, effectuez les tâches suivantes :
-
Assurez-vous que vous pouvez vous connecter aux trois nœuds de l’environnement de production à l’aide de SSH.
-
Vérifiez que les indexeurs sont définis sur Mise à jour selon le calendrier. Voir Modes d’indexation dans le Guide du développeur de l’extension.
-
Préparez l’environnement en mettant à jour les variables spécifiques à l’environnement dans le code de production, en vérifiant la disponibilité et la compatibilité du service et en apportant toute autre modification de configuration requise.
-
-
Surveiller le processus de déploiement
Passez en revue les messages de statut du déploiement et atténuez les problèmes si nécessaire. Consultez les journaux de Cloud pour obtenir des messages de journal détaillés.
Cinq phases de création et de déploiement de l’intégration
Les phases suivantes se produisent dans votre environnement de développement local et dans l’environnement d’intégration. Pour les plans Pro, le code n’est pas déployé dans les environnements d’évaluation ou de production au cours de ces phases initiales.
Phase 1 : validation du code et de la configuration
Lorsque vous configurez initialement un projet, le modèle d’infrastructure cloud fournit une base pour les fichiers de code. Ce référentiel de code est cloné dans votre projet en tant que branche master
.
- Pour commencer :
master
branche est votre environnement de production. - Pour pro :
master
commence comme branche d'origine pour l'environnement d'intégration.
Créez une branche à partir de master
pour votre code personnalisé, vos extensions et modules, ainsi que les intégrations tierces. Il existe un environnement d’intégration à distance pour tester votre code dans le cloud.
Lorsque vous poussez votre code de votre espace de travail local vers le référentiel distant, une série de vérifications et de validations de code se termine avant le démarrage des scripts de build et de déploiement. Le serveur Git intégré valide les éléments que vous transmettez et apporte des modifications. Par exemple, si vous ajoutez un service OpenSearch, le serveur Git intégré vérifie que la topologie de votre cluster est modifiée en conséquence.
Si vous rencontrez une erreur de syntaxe dans un fichier de configuration, le serveur Git rejette la notification push. Voir Bloc de protection.
Cette phase s’exécute également composer install
pour récupérer les dépendances.
Phase 2 : création
Cette phase crée la base de code et exécute les crochets dans la section build
de .magento.app.yaml
. Le hook de build par défaut est la commande php ./vendor/bin/ece-tools
et effectue les opérations suivantes :
- Application de correctifs dans
vendor/magento/ece-patches
et de correctifs facultatifs spécifiques au projet dansm2-hotfixes
- Régénère le code et la configuration injection de dépendance (c’est-à-dire le répertoire
generated/
, qui comprendgenerated/code
etgenerated/metapackage
) à l’aide debin/magento setup:di:compile
. - Vérifie si le fichier
app/etc/config.php
existe dans la base de code. Adobe Commerce génère automatiquement ce fichier s’il ne le détecte pas lors de la phase de création et inclut une liste de modules et d’extensions. S’il existe, la phase de création se poursuit normalement, comprime les fichiers statiques à l’aide de GZIP et se déploie, ce qui réduit le temps d’arrêt dans la phase de déploiement. Pour en savoir plus sur la personnalisation ou la désactivation de la compression de fichiers🔗 voir Options de création.
Une fois l’application créée, elle est montée sur un système de fichiers en lecture seule. Vous pouvez configurer des points de montage spécifiques qui vont être lus/écrits. Vous ne pouvez pas FTP sur le serveur et ajouter des modules. Au lieu de cela, vous devez ajouter du code à votre référentiel local et exécuter git push
, ce qui crée et déploie l’environnement. Pour la structure du projet, voir Structure de répertoires de projet local.
Phase 3 : Préparation du slug
Le résultat de la phase de création est un système de fichiers en lecture seule appelé slug. Cette phase crée une archive et place le slug dans un stockage permanent. La prochaine fois que vous intégrerez du code, si un service n’a pas été modifié, il utilisera le slug de l’archive.
- Rend l’intégration continue plus rapide en réutilisant le code inchangé
- Si le code change, met à jour le slug pour que la prochaine build réutilise
- Permet la restauration instantanée d’un déploiement, si nécessaire
- Inclut des fichiers statiques si le fichier
app/etc/config.php
existe dans le codebase
Le slug comprend tous les fichiers et dossiers à l’exclusion des éléments suivants configurés dans magento.app.yaml
:
"var": "shared:files/var"
"app/etc": "shared:files/etc"
"pub/media": "shared:files/media"
"pub/static": "shared:files/static"
Phase 4 : déploiement des slugs et du cluster
Vos applications et tous les services principaux sont configurés comme suit :
- Monte chaque service dans un conteneur, tel qu’un serveur web, OpenSearch, RabbitMQ
- Monte le système de fichiers en lecture-écriture (monté sur une grille de stockage distribuée à haute disponibilité)
- Configure le réseau afin que les services puissent se « voir » (et uniquement les uns les autres)
Phase 5 : crochets de déploiement
La dernière étape exécute un script de déploiement que vous pouvez utiliser pour rendre anonymes les données dans les environnements de développement, effacer les caches et interroger les outils d’intégration continue externes. Lorsque ce script s’exécute, vous avez accès à tous les services de votre environnement, tels que Redis.
Si le fichier app/etc/config.php
n’existe pas dans le codebase, les fichiers statiques sont compressés à l’aide de gzip
et déployés au cours de cette phase, ce qui allonge la durée de la phase de déploiement et de la maintenance du site.
Il existe deux hooks de déploiement. Le hook pre-deploy.php
effectue le nettoyage et la récupération nécessaires des ressources et du code générés dans le hook de build. Le hook php ./vendor/bin/ece-tools deploy
exécute une série de commandes et de scripts :
-
Si Adobe Commerce n’est pas installé, il s’installe avec
bin/magento setup:install
et met à jour la configuration du déploiement, lesapp/etc/env.php
et la base de données pour l’environnement spécifié, tel que Redis et les URL de site web. Important : lorsque vous avez terminé le premier déploiement lors de la configuration, Adobe Commerce a été installé et déployé dans tous les environnements. -
Si Adobe Commerce est installé, effectuez les mises à niveau nécessaires. Le script de déploiement exécute
bin/magento setup:upgrade
pour mettre à jour le schéma et les données de la base de données (ce qui est nécessaire après les mises à jour de l’extension ou du code principal). Il met également à jour la configuration du déploiement, lesapp/etc/env.php
et la base de données pour votre environnement. Enfin, le script de déploiement efface le cache d’Adobe Commerce. -
Le script génère éventuellement du contenu web statique à l’aide de la
magento setup:static-content:deploy
de commande . -
Utilise des portées (indicateur
-s
dans les scripts de version) avec un paramètre par défaut dequick
pour la stratégie de déploiement de contenu statique. Vous pouvez personnaliser la stratégie à l’aide de la variable d’environnementSCD_STRATEGY
. Pour plus d’informations sur ces options et fonctionnalités, consultez Stratégies de déploiement de fichiers statiques et l’indicateur de-s
pour Déployer des fichiers d’affichage statiques.
.magento
, puis le script supprime le répertoire et son contenu. Votre environnement de développement local n’est pas affecté.Après le déploiement : configurer le routage
Pendant l’exécution du déploiement , le processus interrompt le trafic entrant au point d’entrée pendant 60 secondes et reconfigure le routage de sorte que le trafic web arrive à votre cluster nouvellement créé.
Un déploiement réussi supprime le mode de maintenance pour permettre un accès normal et crée des fichiers de sauvegarde (BAK) pour les fichiers de configuration app/etc/env.php
et app/etc/config.php
.
Activez la génération de contenu statique à l’aide de la variable SCD_ON_DEMAND
et configurez le hook post_deploy
de sorte qu’il vide le cache et précharge (réchauffe) le cache une fois que le conteneur commence à accepter les connexions et pendant le trafic entrant normal.
Pour consulter les journaux de génération et de déploiement, voir Afficher les journaux.