Maîtriser les migrations - Des moyens plus rapides, plus simples et plus sûrs de déplacer votre site de A à B

Les migrations peuvent être délicates ! Nous connaissons tous ce sentiment de frustration (ou de peur totale) lorsque nous voyons quelqu'un échouer, mais nous connaissons aussi le sentiment de soulagement lorsqu'une migration réussit. Avec toutes les complexités et les nuances des migrations, comment pouvons-nous augmenter notre taux de réussite et gagner du temps pour nous concentrer sur le travail que nous voulons vraiment faire ?

Que vous ayez besoin de copier un projet établi sur votre ordinateur local ou de déployer une poignée de mises à jour incrémentielles en production, suivez-nous pendant que nous expliquons comment vous pouvez accélérer, simplifier et réduire les risques de vos migrations.

Haut-parleurs:

• Kevin Hoffman, chef de produit senior chez WP Engine
• Austin Wendt, chef de produit senior chez WP Engine

Diapositives de la session :

Transcription:

AUSTIN WENDT : Bienvenue, tout le monde, et merci de vous joindre à nous. Nous sommes ravis de vous avoir. Et bienvenue à la conférence DE{CODE}.

Je m'appelle Austin Wendt, je suis chef de produit senior ici chez WP Engine, travaillant à la construction de notre produit local. Et mon collègue, Kevin, et moi-même, que vous rencontrerez ici dans une minute, sommes ravis de vous parler aujourd'hui de la construction plus intelligente, notamment en termes de maîtrise de vos migrations. Nous couvrirons donc des moyens plus rapides, plus faciles et plus sûrs de déplacer votre site du point A au point B afin que vous vous sentiez en confiance dans ces flux de travail de développement, que vous ameniez un site dans un environnement de développement local et sûr, ou que vous ' re prêt à pousser ce site en direct au fil du temps.

Je vais couvrir un ordre du jour rapide avant de plonger. Donc, ce que nous allons couvrir aujourd'hui, c'est que nous allons présenter les trois types de migrations auxquelles nous aimons penser ici chez WP Engine lorsque nous parlons de déplacer le code. Nous définirons notre flux de travail de migration idéal et vous expliquerons au cours de cette présentation les différentes manières de déplacer votre code. Nous couvrirons l'exportation de votre site existant et sa mise hors service - l'importation dans un environnement de développement local.

Nous parlerons de la réalisation d'un premier déploiement - donc lorsque vous mettez votre site en ligne pour la première fois, à quoi cela ressemble, et quelques façons d'y parvenir Et puis de synchroniser ces deux environnements au fil du temps. Alors plongeons-y dedans.

Les trois types de migrations auxquelles nous pensons– il y a trois options principales qu'un utilisateur pourrait tenter d'accomplir. Le premier est distant vers local. Donc, si vous avez déjà un site hébergé quelque part sur le Web et que vous souhaitez l'intégrer à un environnement local, peut-être un l minuscule, c'est utile lorsque vous commencez peut-être à travailler sur le site existant d'un client. Donc, soit vous avez hérité d'un nouveau client, soit un client vous demande d'apporter des modifications et de le déposer dans un endroit sûr, afin que vous puissiez résoudre ce problème dans un environnement à faible risque.

Également très utile lorsque vous essayez simplement d'extraire les dernières modifications de la base de données, afin de vous assurer que votre environnement distant et votre environnement de production - ou excusez-moi, environnement de développement - sont aussi proches que possible. Le second est local à distant. Ainsi, lorsque vous revenez de votre ordinateur personnel au serveur hébergé quelque part - soit vous déployez un site complet pour la première fois, soit vous avez apporté des modifications au code et vous poussez ces modifications, appelez pour les thèmes, ou pour les plugins, peu importe ce que vous aimeriez voir reflété en direct sur votre site.

Et le second– excusez-moi, le troisième est de distance à distance. Nous ne nous plongerons pas trop dans celui-ci aujourd'hui, mais c'est quelque chose qui est possible avec les outils que vous découvrirez. Vous l'utiliserez généralement lorsque vous changez de fournisseur d'hébergement - donc en passant de l'hôte A à l'hôte B, ou potentiellement lorsque vous vous déplacez entre les environnements de développement, de mise en scène et de production, où que votre site soit hébergé.

Donc, sur ce, je vais laisser la parole à Kevin pour qu'il se présente et nous lance sur ce à quoi ressemble ce flux migratoire idéal. Kevin, emporte-le.

KEVIN HOFFMAN : Salut, merci, Austin. Je m'appelle donc Kevin Hoffman, je suis le chef de produit de WP Migrate. Je veux lancer les choses aujourd'hui en commençant par un plan de match du type de migrations dans lequel nous allons nous lancer. Ainsi, chaque fois que vous passez d'un environnement distant à votre machine locale et que vous sauvegardez sur un hôte distant, cela peut être une tâche ardue. Mais nous voulons que vous quittiez cette présentation avec un plan de match de solutions afin que vous puissiez effectuer vous-même ces migrations en toute confiance.

Et pour commencer, nous voulons sortir le site existant de l'ancien hébergeur. Cela va donc inclure une exportation complète du site à l'aide de WP Migrate. Nous allons ensuite passer à Local, où nous pouvons effectuer nos modifications de développement local, puis déployer ce site sur notre nouvel hôte.

Donc, pour commencer, je vais passer à un flux d'exportation de site complet à l'aide de WP Migrate. Vous vous demandez peut-être pourquoi utilisons-nous une exportation complète du site dans cette situation ? Pourquoi ne pas pousser ou tirer directement entre deux environnements ? Eh bien, il y a plusieurs raisons à cela.

Pour commencer, je vais utiliser la version Pro de WP Migrate, mais vous pouvez également suivre WP Migrate Lite, qui est la version gratuite de notre plugin sur le répertoire des plugins WordPress.

Les quatre principales raisons pour lesquelles nous utilisons une exportation complète du site dans cette situation sont d'abord parce qu'il s'agit d'une migration à sens unique. Nous voulons quitter l'hôte distant et nous n'avons pas l'intention d'y retourner. Il n'y a pas non plus d'installation locale existante dans laquelle déplacer le site. Si c'était le cas, nous pourrions peut-être utiliser une migration push ou une migration pull pour faire descendre le site dans la machine locale. Mais comme il n'y a pas d'installation existante, une importation par glisser-déposer en local est la plus logique.

Et enfin, en faisant une exportation complète du site, nous obtenons également une sauvegarde gratuite. L'ensemble du site sera encapsulé dans un fichier zip groupé, ce qui constitue une excellente sauvegarde avant d'apporter de futures modifications.

Donc, pour commencer, passons à WP Migrate et voyons comment cela fonctionne.

Ainsi, lorsque vous ouvrirez WP Migrate pour la première fois, vous aurez six actions devant vous. Parce que nous voulons sortir le site de l'hôte distant le plus rapidement possible, nous allons choisir l'action d'exportation. L'ouverture du profil d'exportation nous donne la possibilité de configurer les options de la base de données, ainsi que les médias, les thèmes, les plugins et les fichiers principaux de WordPress.

Continuons et commençons par la configuration de la base de données. Maintenant, si je le voulais, je pourrais exclure certaines tables ou certains types de messages de cette migration. Mais pour l'instant, je veux utiliser la configuration par défaut et simplement sortir le site entier de l'hôte distant. Je veux mentionner les champs standard de recherche et de remplacement, comme l'URL ou le chemin de l'installation WordPress locale, sur le site que nous exportons.

Maintenant, si vous effectuiez une migration manuelle, vous souhaiterez peut-être déplacer ces valeurs et les modifier pour qu'elles correspondent à la destination. Cependant, comme nous utilisons Local, il est suffisamment intelligent pour s'occuper de cette recherche et de ce remplacement pour nous, nous n'avons donc pas à remplir ces champs facultatifs. Nous pouvons les laisser vides et passer à autre chose.

La prochaine étape est la recherche et le remplacement personnalisés. Il s'agit de la possibilité de rechercher n'importe quelle chaîne dans ma base de données WordPress ou dans mon contenu sur mon site. Par exemple, si j'ai peut-être un ancien nom de société et que je souhaite le remplacer par le nouveau nom de ma société, je peux le faire via ces champs de recherche et de remplacement personnalisés. Et je peux ajouter des lignes supplémentaires, si nécessaire.

Cela prend donc soin de la base de données. Passons à nos téléchargements de médias. Maintenant, parce que je déplace l'ensemble du site, je souhaite sélectionner Exporter tous les téléchargements de médias. Mais je veux exclure certains fichiers comme les journaux, les sauvegardes et les caches, qui pourraient gonfler l'exportation.

Au fur et à mesure que nous passons aux fichiers de thème, je souhaite inclure tous mes thèmes. Pas cette fois, juste les thèmes actifs, car je ne suis concerné que par les thèmes qui affectent activement le site en direct.

De même, avec les plugins, je souhaite uniquement exporter mes plugins actifs. Et avec les fichiers principaux de WordPress, je veux aller de l'avant et les inclure, car je veux m'assurer que mon noyau WordPress correspond à la version exacte du site à partir duquel j'exporte.

Avec le profil entièrement configuré, je peux maintenant lancer l'exportation, qui va parcourir rapidement mes tables de base de données, les téléchargements de médias, les thèmes, les plugins et les fichiers principaux de WordPress.

À ce stade, la base de données et tous les fichiers du site sont regroupés dans un seul fichier zip pratique. Ainsi, en seulement 18 secondes, l'ensemble du site a été compressé.

Je suis maintenant prêt à passer à Local. Et avant de faire cela, je veux jeter un coup d'œil rapide à l'intérieur du fichier zip pour voir ce qu'il y a dedans. Vous pouvez voir que j'ai un répertoire de fichiers. Cela inclut tous les fichiers WordPress, y compris mon contenu WP, mes plugins, mes thèmes et mes téléchargements. Et j'ai aussi le vidage de la base de données.

Et un autre fichier, qui est vraiment important et unique à WP Migrate - le fichier JSON d'exportation WP Migrate comprend des informations clés sur le site qui a été exporté, telles que la version PHP et la version MySQL, de sorte que lorsque Local s'occupe de l'importation , il peut correspondre le plus possible à cet environnement distant.

Donc, avec cela, vous êtes prêt à importer dans Local. Et je le renverrai à Austin.

AUSTIN WENDT : Génial, merci, Kevin. Ouais, je suis ravi de couvrir, comme Kevin l'a mentionné, comment nous pouvons importer ce fichier zip dans Local et prêt à commencer à construire. Mais d'abord, je veux m'assurer de présenter ce qu'est Local. Si vous n'êtes pas familier, Local est l'outil de développement WordPress numéro un, construit par les humains ici chez WP Engine, et nous sommes très heureux de partager et d'offrir gratuitement à la communauté.

C'est donc un outil de développement gratuit. Si vous n'en avez pas entendu parler, veuillez le consulter, localWP.com, nous serions ravis que vous utilisiez le produit. Mais aujourd'hui, nous allons utiliser Local pour faciliter ce flux de travail.

Et pourquoi locale ? Semblable à tout environnement spécifique à votre machine, il présente un risque très faible. Et comme Kevin l'a dit, ce que Local va essayer de faire lorsque vous importez cette exportation depuis WP Migrate, c'est que nous allons imiter étroitement l'environnement de production. Donc, aussi proche que possible, la version WordPress, la version PHP, la base de données, votre machine locale devrait imiter ce qui se passe en production, de sorte que si vous dépannez ou essayez de voir ce qui ne va pas, Local devrait pouvoir dire vous, et soyez aussi proche que possible de ce qui se passe, sur votre environnement hébergé.

Un autre avantage clé de faire cela avec Local est que le flux de travail que Kevin vient de mentionner est indépendant de l'hôte. Ainsi, quel que soit l'endroit où vous hébergez, que ce soit avec Flywheel ou WP Engine, vous pourrez exporter ce site et le déposer en local très rapidement et facilement.

Je vais donc passer à une démo et vous montrer à quoi cela ressemble dans l'interface utilisateur locale.

Génial, j'ai donc déjà fait un WP Migrate, et j'ai enregistré ce zip sur mon bureau. Et quand je vais créer un site dans Local, il y aura cette nouvelle zone de glissement qui indique que vous pouvez faire glisser et déposer des fichiers zip ici. Ce qui est également bien avec Local, c'est que je peux le faire à partir de n'importe quel écran de l'interface utilisateur. Donc, si je fais glisser et déposez ce fichier zip sur Local, il va me suggérer le nom du site à partir de ce fichier JSON d'exportation de migration WP que Kevin a mentionné.

C'est présélectionné mon PHP, mon serveur web, ma base de données. Et puis, je clique sur Créer, et Local s'occupe du reste. Donc, Local décompresse activement ce fichier zip, importe tous ces fichiers WordPress et configure ce site sur ma machine dans un état aussi proche de la production que possible.

Pendant que cela tourne, il va demander la permission de mettre à jour mon fichier hôte, ce que je vais entrer mon mot de passe et lui permettre de faire. Mais ensuite, Local commence à ajouter WordPress et vous êtes prêt à partir.

Pendant que cela se termine, quelque chose que je vais souligner très rapidement est que vous pouvez voir sur le côté gauche - la possibilité de regrouper vos sites est nouvelle dans Local au cours des deux dernières semaines. Je vais donc faire glisser et déposer Garrett's Grocery dans ma section de démonstration DE{CODE} - ce qui est une bonne façon que je vous encourage à consulter pour organiser vos sites, peut-être les regrouper par client ou par version, connecté à WP Moteur ou pas, ce qui vous convient le mieux. Alors essayez ça.

Mais Local termine ici, il change ce domaine de site. Et ce que cela va faire, c'est le configurer sur ma machine pour qu'il soit disponible, comme vous pouvez le voir ici, sur monsite.local. Si je clique sur Ouvrir le site, voici Garrett's Grocery. Je suis donc effectivement parti de mon environnement hébergé, je l'ai fait glisser et déposé dans Local, et je l'ai exécuté sur ma machine en moins de deux minutes, ce qui est génial.

Donc, avec cet exemple, ce que nous avons montré est de pouvoir le prendre à partir de votre ancien hôte, quel que soit l'endroit où il se trouve sur Internet, et avec une combinaison d'exportation de site complet WP Migrate, en l'introduisant dans Local et en imitant votre environnement de production en moins de quelques minutes.

Maintenant, la question est, une fois que je l'ai dans Local, je suis prêt à commencer à apporter des modifications. Comment puis-je le retirer et le remettre en ligne sur Internet ? Pour retirer votre site de Local et le remettre à votre hôte, nous utiliserons Local Connect pour le déployer sur WP Engine ou sur Flywheel. Que ce soit à partir d'une migration complète du site ou de migrations partielles.

Mais pourquoi voudriez-vous faire un déploiement complet du site ? Le premier déploiement d'un site entier sur votre hébergeur en est un bon exemple. Alors peut-être que le site n'existe pas encore du tout, ou peut-être qu'il s'agit simplement d'un site basé sur un modèle sur l'hôte. Si vous souhaitez inclure des thèmes entiers ou des modifications de plug-in, ou peut-être êtes-vous simplement prêt à écraser complètement le site actuel qui se trouve sur l'hôte aujourd'hui. Alors peut-être qu'il a déjà du contenu, mais ce qui est là maintenant n'est plus productif ou propice, et vous êtes prêt à simplement l'effacer, vous utiliseriez un déploiement complet du site.

Donc, en utilisant Local, c'est assez facile à réaliser. Et je vais vous montrer une démo de ce à quoi cela ressemble. J'ai donc Garrett's Grocery ici, et j'ai apporté une série de modifications au site Web que je suis prêt à mettre en place. Maintenant, Local a le concept de Local Connect, comme je l'ai mentionné - il y a cette icône de nuage sur le côté gauche, pour Connect. Il y a aussi un Connect to Host en bas à droite, qui me permettra de connecter WP Engine ou Flywheel.

Pour aujourd'hui, je vais accomplir cela en accédant à l'onglet Connexion et en cliquant sur Se connecter à une plate-forme. Je vais me connecter à mon compte WP Engine, que je vous ai épargné en me regardant me connecter. Ce que vous pouvez voir, c'est que Local Connect attire tous les sites auxquels j'ai accès sur WP Engine. Maintenant, ce que je vais faire, c'est que je vais revenir à Garrett's Grocery dans mon aperçu. En bas à droite, je sélectionne Se connecter à WP Engine.

Local va vérifier que ce site est compatible avec l'infrastructure de WP Engine. Donc, en utilisant WordPress et PHP à jour, puis je peux cliquer sur Push.

Push va me permettre de choisir la vue que je veux écraser sur WP Engine. Cela me permettra de choisir l'environnement. Je choisirai donc le site d'Austin Wendt, et je choisirai Production. Et ce que vous verrez se produire sur le côté droit de l'écran, c'est que Local détermine la liste des fichiers.

Cela signifie que local consiste essentiellement à exécuter un diff entre ce qui est sur ma machine et ce qui existe sur le serveur, et à me le fournir afin que je puisse vraiment voir et comprendre les changements que je suis sur le point d'apporter. Donc, comme il s'agit d'un déploiement de site complet, vous pouvez voir que rien ne se passe dans mon environnement local, mais je vais écraser tout ce qui se trouve sur la production, comme vous pouvez le voir avec ces X rouges sur le côté droit.

Alors je clique, Push to WP Engine, et Local commence à s'occuper du reste. Cette vidéo entière dure environ quatre minutes - je vous épargnerai de regarder ça avec moi, pendant que je suis assis ici. Ce qui se passe, c'est que Local emballe ces fichiers. Il commence à télécharger ces fichiers sur WP Engine. Et commencer à analyser, comme je l'ai dit, les différences entre ce qu'il y a sur ma machine et ce qu'il y a sur le serveur WP Engine.

Ce même flux de travail s'appliquerait également à Flywheel, si vous y hébergez. Nous suivrons le même flux en entrant cette différence de fichier entre votre machine et le serveur.

Alors maintenant, Local commence à emballer la base de données. Il pousse également cela vers WP Engine. Il supprime donc toutes les tables existantes qui existent sur le serveur distant et les remplace par ce qui vient de ma machine.

Dans le cadre de cette transition de base de données, il va examiner le domaine du site et effectuer une recherche et un remplacement pour moi, comme vous pouvez le voir maintenant. Ainsi, tous mes liens et URL stockés dans ma base de données seront mis à jour, ainsi que les préfixes de table, pour fonctionner correctement dans l'environnement de production.

Il mettra donc à jour ces préfixes de table pour moi. Et juste comme ça, mon site a été poussé vers WP Engine.

Donc, en recommençant, Garrett's Grocery est toujours sur ma machine. Mais aussi, si je vais dans l'onglet Connecter, je peux voir ce site Austin Wendt sur lequel j'ai poussé sur la droite, il dit qu'il est connecté à Garrett's Grocery. Et si je devais cliquer sur le nom du site, Austin Wendt, il s'ouvrira dans un navigateur pour que je me montre ce nouveau contenu en direct sur Internet.

Maintenant que nous comprenons comment utiliser Local pour réaliser un déploiement complet de site, j'aimerais expliquer comment nous pouvons utiliser Local pour synchroniser également les environnements à l'aide d'une fonctionnalité que nous connaissons sous le nom de MagicSync.

MagicSync est donc un autre mot pour les migrations incrémentielles. Donc, ne déplacez que de petits morceaux de code entre votre environnement local et le serveur distant. Et pourquoi voudriez-vous faire cela ?

Alors peut-être que vous ne voulez pas remplacer l'intégralité du site. Vous n'avez apporté que de petites modifications partielles à un site existant que vous êtes prêt à mettre en ligne. Ce qui est également bien avec Local - un Local vous permettra, comme je l'ai mentionné, cette fonction de comparaison, de choisir les fichiers que vous souhaitez inclure, voire exclure. Donc, un grand cas d'utilisation courant ici est peut-être que j'ai fait beaucoup de choses sur ma machine, mais je veux exclure les médias push et pull, car c'est une partie très lourde et intensive de mon site. Je peux simplement désélectionner les médias.

Nous allons donc plonger ici dans une démo de ce à quoi ressemble MagicSync. Donc, encore une fois, ici, j'ai Garrett's Grocery - disons que j'ai fait un autre ensemble de modifications plus petites cette fois, et je suis prêt à voir cela reflété en direct sur WP Engine. Même flux de travail ici - en bas à droite de mon écran, je reviens pour pousser vers WP Engine. C'est déjà présélectionné le site d'Austin Wendt pour moi, et l'environnement, en me souvenant de la dernière fois que je l'ai fait.

Et cette fois, ce sera plus court – cela détermine, encore une fois, ce différentiel entre ce qui se trouve sur ma machine et ce qui se trouve sur les serveurs WP Engine. Il va donc revenir ici, et il y a un plus petit ensemble de modifications qu'il détecte avoir été apportées au site. Je peux désélectionner toutes les modifications de fichier que je veux. Je peux sélectionner uniquement mon dossier de contenu WP.

Ou peut-être dans ce cas, disons que je veux seulement pousser ma base de données. Je peux donc cocher la case de la base de données et appuyer sur Push. Alors maintenant, ce qui se passe est le même flux de travail que nous avons vu auparavant, sauf que Local ne pousse aucun fichier vers WP Engine. Il ne s'agit que de remplacer les modifications de la base de données que j'ai apportées sur ma machine par la base de données qui se trouvait actuellement sur le serveur WP Engine.

Donc, un flux de travail similaire ici - nous allons en fait suivre ce processus, car cela ne prend pas autant de temps. Parce que le différentiel est plus petit. Nous allons donc télécharger la base de données sur WP Engine. La section locale va, encore une fois, aller de l'avant pour moi et faire cette recherche et ce remplacement. Ainsi, il détectera si les préfixes de table ont changé, les URL qui étaient différentes sur ma machine devant être reflétées sur l'hôte distant.

Il fera ces mises à jour pour moi. Et dans un peu moins d'une minute environ, les modifications du site que j'ai apportées sur ma machine seront poussées vers WP Engine, et prêtes à être consommées par des collègues et des pairs qui souhaitent simplement revoir le travail que j'ai fait, peut-être que j'ai poussé vers un environnement de développement ou s'il est en direct sur le Web en production, et prêt pour mes clients ou clients - ou simplement les consommateurs à voir sur le Web.

Donc, juste comme ça, le site a été poussé vers WP Engine et si je revenais sur le navigateur, vous verriez le site mis à jour et reflété là-bas. Alors maintenant que nous comprenons comment utiliser Local pour accomplir des migrations incrémentielles, j'aimerais redonner la parole à Kevin pour vous montrer une autre façon d'accomplir cela en utilisant l'outil WP Migrate.

KEVIN HOFFMAN : Salut, merci, Austin. J'apprécie que vous nous guidiez à travers le flux de travail Local vers WP Engine, mais nous savons que vous n'avez pas toujours le contrôle sur votre fournisseur d'hébergement. Ainsi, le prochain workflow va vous montrer comment migrer entre deux environnements WordPress. Dans ce cas, passer de Local à n'importe quel autre hébergeur.

Pour ce faire, nous allons utiliser un concept appelé pousser et tirer, en utilisant WP Migrate. Maintenant, pourquoi feriez-vous une poussée ou une traction ? Contrairement à une exportation complète du site, il s'agit d'une migration bidirectionnelle. Cela signifie que les deux sites existent déjà, et cela nécessite un peu plus d'investissement initial pour un gain à plus long terme.

Ainsi, une fois cette configuration terminée, vous serez prêt à gérer vos migrations incrémentielles au fil du temps et à synchroniser en permanence deux environnements.

Voyons donc à quoi cela ressemble. Supposons donc que votre site soit prêt à être déployé sur votre hôte distant. Vous avez un certain nombre de publications et un certain nombre d'images dans votre médiathèque. Nous allons prendre ce contenu et le déplacer vers un nouveau site qui n'a actuellement aucune publication et aucune image dans la médiathèque.

L'approche différente que nous allons adopter ici consiste à utiliser une migration push. Et la première chose qu'il m'a demandée, ce sont les informations de connexion du site distant. Je peux donc basculer vers le site distant et, dans mon onglet paramètres, copier les informations de connexion directement dans mon presse-papiers. Je souhaite également activer la migration push, afin de pouvoir accepter ces demandes push du site local.

En collant ces informations dans la zone d'informations de connexion, je suis maintenant connecté au site distant et je suis prêt à configurer les options de ma base de données. La grande différence que vous remarquerez ici, par rapport à notre flux de travail d'exportation, est que les deux côtés Rechercher et Remplacer de l'URL et du chemin sont complètement remplis pour nous. Et c'est parce que WP Migrate est sur les deux sites, a accès à ces informations et peut s'en occuper pour nous sans que nous ayons à saisir quoi que ce soit pour lancer la migration.

Je ne vais pas faire de recherche et de remplacement personnalisés, mais je vais inclure tous mes téléchargements de médias depuis la bibliothèque, ainsi que tous mes thèmes et mes plugins. Maintenant, une caractéristique unique que vous remarquerez ici lors de la sélection de mes plugins est qu'elle me montre quel est l'état de ce plugin sur le site distant. Maintenant, dans ce cas, il n'y a pas de plugins là-bas, donc tous ces plugins seront ajoutés pour la première fois, et le numéro de version actuel est indiqué lorsque vous survolez cette icône.

Je vais continuer et enregistrer ce profil pour une utilisation future, et je vais le nommer Push Full Site. Ainsi, chaque fois que j'ai besoin de pousser un site complet vers cet emplacement distant, je peux simplement revoir ce profil et l'exécuter.

Lorsque j'exécute le profil, vous le verrez à nouveau parcourir les tableaux, les téléchargements de médias, les thèmes, les plugins et vous obtiendrez des informations sur la taille des demandes au fur et à mesure de la migration.

Une fois la migration terminée, vous pouvez continuer et fermer le modal, et vos deux environnements sont maintenant synchronisés.

À ce stade, vous voudrez peut-être revoir l'écran de votre profil pour vérifier comment ce profil enregistré est disponible pour que vous puissiez revenir en arrière, si jamais vous avez besoin de le réexécuter.

Il s'agit donc d'un déploiement complet du site avec un profil de sauvegarde dans WP Migrate. Mais vous vous demandez peut-être qu'en est-il du déploiement de modifications incrémentielles ? Donc, comme Austin vous l'a montré, en utilisant MagicSync en local, c'est une autre façon de le faire avec WP Migrate. Je vais donc créer un autre profil push, entrer les mêmes informations de connexion, mais cette fois, lorsque je sélectionne mes téléchargements de médias, je vais uniquement pousser les téléchargements de médias nouveaux et mis à jour.

Cela signifie que la première fois que la migration s'exécute, elle inclura tout. Mais chaque migration ultérieure n'inclura que les fichiers multimédias qui ont été modifiés.

Il s'agit d'un excellent flux de travail chaque fois que vous poussez du contenu et des fichiers multimédias sans avoir à vous soucier des thèmes ou des plugins. Je vais donc maintenant enregistrer ce profil, et je le nommerai Push Content and Media.

Cela me laisse donc maintenant avec deux profils de migration que je peux utiliser à deux fins différentes. Ils sont enregistrés sur l'écran de mon profil et sont disponibles chaque fois que j'ai besoin d'y revenir. Je pourrais même configurer un profil d'extraction pour ensuite extraire les données de production vers ce site local et maintenir les deux environnements synchronisés dans les deux sens.

Cela conclut donc nos flux de travail utilisant local et WP Migrate pour passer de distant à local, et revenir à distant.

Donc, comme vous pouvez le voir, maintenant notre plan de match est terminé, nous avons des solutions pour sortir du site distant en utilisant une exportation complète du site depuis WP Migrate, faites glisser et déposez-le en local, puis poussez jusqu'à WP Engine ou Flywheel, ou tout autre hébergeur. Ce n'est donc que la pointe de l'iceberg en ce qui concerne les solutions de migration et ce qui est possible lorsque vous utilisez WP Migrate et Local ensemble.

Nous espérons donc que cela vous donnera un plan de match la prochaine fois que vous devrez exécuter vos propres migrations. Au plaisir de vous entendre sur nos comptes Twitter pour WP Migrate et Local, et nous espérons que vous apprécierez le reste de DE{CODE]. Merci de vous joindre a nous.