Comment synchroniser votre environnement de développement local avec la production

Lorsque votre configuration de développement locale ne correspond pas à votre serveur de production, vous codez essentiellement à l'aveugle.

Vous pourriez penser que tout fonctionne. Cela fonctionne probablement, sur votre machine. Mais ce n'est pas là que cela compte.

Avoir un processus fiable pour synchroniser le développement local avec la production n'est pas juste un plus. C'est ce qui sépare les professionnels des personnes qui croisent les doigts à chaque déploiement.

Dans cet article, je vais vous présenter des méthodes éprouvées pour maintenir vos environnements synchronisés. Vous en trouverez une qui correspond à votre flux de travail !

Voici les points clés à retenir :

• La synchronisation des environnements élimine les problèmes de compatibilité et détecte les bugs avant que les utilisateurs ne les voient
• Vous pouvez utiliser Duplicator pour un flux de synchronisation local convivial pour débutants ou GitHub + WP-CLI pour un contrôle en ligne de commande
• Téléchargez toujours la base de données depuis la production et ne poussez que les modifications de code vers le haut pour éviter d'écraser les données en direct
• Les sites WordPress ont trois parties à synchroniser : le code (Git), la base de données (WP-CLI) et les fichiers multimédias (rsync)
• Sauvegardez toujours avant de synchroniser quoi que ce soit, utilisez des environnements de staging pour les tests et maintenez un fichier .gitignore approprié

Table des matières

Pourquoi synchroniser vos environnements locaux et de production ?

Vous pourriez probablement survivre sans synchroniser les environnements. Beaucoup de gens le font. Ils gèrent simplement les bugs surprises occasionnels, le problème de production aléatoire qui ne s'est pas produit localement, et l'incertitude lancinante chaque fois qu'ils poussent une mise à jour.

Mais pourquoi vous infliger cela ?

Garder vos environnements locaux et de production synchronisés élimine des tonnes de problèmes. Voici ce que vous obtenez réellement en le faisant correctement.

Attrapez les erreurs avant qu'elles ne soient en ligne

Un environnement local synchronisé reflète la configuration réelle de votre serveur de production. Il aura la même version de PHP, la même structure de base de données et les mêmes plugins aux mêmes versions.

Cela compte plus que vous ne le pensez.

Lorsque vous travaillez sur une configuration locale qui correspond à la production, les problèmes de compatibilité apparaissent immédiatement. Vous les attrapez à votre bureau, pas devant les utilisateurs. C'est la différence entre une gêne mineure et un vrai problème.

Un bac à sable réaliste pour les tests

Tester avec des données factices est bien pour construire des fonctionnalités initiales. Mais à un moment donné, vous devez voir comment les choses se comportent réellement.

Le contenu réel des utilisateurs est désordonné. Les catalogues de produits ont des cas limites étranges.

Votre site local a besoin de ces données réelles pour vous donner une image précise de ce qui se passe.

La synchronisation depuis la production vous donne les articles, utilisateurs et produits réels avec lesquels votre code interagira. Vous ne devinez plus ; vous testez par rapport à la réalité.

Aucun problème de compatibilité

Chaque développeur a dit, « Mais ça marchait sur ma machine » au moins une fois. C'est pratiquement un mème à ce stade.

Mais c'est aussi le symptôme d'environnements qui ne correspondent pas. Lorsque votre configuration locale est pratiquement identique à la production, cette excuse disparaît. Si ça marche localement, ça marche en direct.

Ce genre de confiance change votre façon de travailler. Vous arrêtez de douter de chaque déploiement.

Améliorer la collaboration d'équipe

Lorsque vous travaillez seul, vous pouvez vous en sortir avec un processus désordonné. Ajoutez un deuxième développeur, et les choses se compliquent rapidement.

Un processus de synchronisation cohérent signifie que tout le monde part de la même base. Vous testez tous sur la même base de données, en utilisant la même structure de contenu et en exécutant la même configuration d'environnement.

Sans cela, vous vous retrouvez avec trois versions différentes de « local », et personne n'est sûr de celle qui est la plus proche de la production. Ce n'est pas de la collaboration ; c'est le chaos.

Comment synchroniser votre environnement local avec la production

Vous pourriez le faire manuellement. Exportez la base de données via phpMyAdmin, téléchargez-la, importez-la localement, et recherchez et remplacez manuellement toutes les URL dans le fichier SQL. Ensuite, transférez par FTP sur votre serveur, compressez le dossier uploads, téléchargez-le, extrayez-le localement…

Je suis épuisé rien qu'à l'écrire.

Les méthodes manuelles sont fastidieuses et risquées. Manquez un remplacement d'URL, et votre site local commence à pointer vers les ressources de production. Oubliez de mettre à jour correctement un tableau sérialisé, et vous avez corrompu votre base de données.

Il existe une meilleure façon. Voici comment synchroniser vos environnements de développement local et de production :

• Duplicator : Plugin de migration avec remplacement automatique d'URL et installateurs guidés — parfait pour les débutants ou les synchronisations rapides
• GitHub + WP-CLI : Contrôle en ligne de commande pour synchroniser le code via Git, la base de données via les exportations WP-CLI, et les médias via rsync — idéal pour les développeurs qui souhaitent un contrôle granulaire

Synchroniser les sites locaux et de production avec Duplicator

C'est la méthode la plus simple, surtout si vous n'êtes pas à l'aise dans le terminal.

Duplicator crée un instantané complet de votre site et vous fournit un installateur qui gère automatiquement toutes les parties délicates. Vous n'aurez pas à vous soucier des remplacements d'URL manuels ou des maux de tête liés à la configuration de la base de données.

Extraire de la production vers le local (le flux de travail courant)

C'est ce que vous ferez le plus souvent. Vous voulez récupérer l'état actuel de votre site en ligne et travailler avec localement.

Commencez par installer Duplicator Pro sur votre site de production et créez une nouvelle sauvegarde complète du site. Considérez cela comme prendre un instantané de votre site entier à cet instant précis.

La création de la sauvegarde prend quelques minutes selon la taille de votre site. Une fois terminée, vous aurez deux fichiers : une archive (généralement un fichier .daf ou .zip) et un script d'installation (un fichier .php). Téléchargez les deux.

Maintenant, allez sur votre environnement local. Créez un répertoire vide où vous souhaitez que votre copie locale réside. Déposez les deux fichiers — l'archive et l'installateur — dans ce répertoire vide.

Ouvrez votre navigateur et naviguez vers ce répertoire. Quelque chose comme http://localhost/mysite/installer.php. L'assistant d'installation de Duplicator se lance.

L'assistant vous guide pour vous connecter à votre base de données locale et gère automatiquement tous les remplacements d'URL.

Il sait que votre site de production était à https://mysite.com et que votre site local est à http://localhost/mysite. Il corrige chaque référence dans la base de données sans que vous n'ayez à toucher à quoi que ce soit.

Cinq minutes plus tard, vous avez une copie locale parfaite de votre site de production.

Pousser du local vers la production

Ce flux de travail va dans le sens inverse. Vous prenez votre site local et le déployez en production.

Soyez prudent ici. Ceci est vraiment réservé aux lancements de nouveaux sites ou aux refontes complètes. Si vous avez un site en ligne avec des utilisateurs actifs, vous ne voudrez probablement pas faire cela. Vous écraserez leurs publications, commentaires et commandes récents.

Si vous avez besoin de pousser du local vers la production, le processus est similaire mais inversé.

D'abord – et je ne saurais trop insister là-dessus – sauvegardez complètement votre site de production avant de faire quoi que ce soit d'autre.

Ensuite, créez une sauvegarde de votre site local à l'aide de Duplicator et téléchargez-la. Téléversez les deux fichiers de sauvegarde sur votre serveur de production via FTP ou faites glisser l'archive sur la page Importation.

Encore une fois : ne faites cela que si vous êtes sûr de vouloir remplacer complètement la production. Pour vous assurer de pouvoir facilement annuler toute modification inattendue, assurez-vous de définir un point de récupération.

Duplicator vous fournira une URL de récupération qui restaure une sauvegarde récente, même si votre site est complètement cassé.

Synchroniser les sites locaux et de production avec GitHub et WP-CLI

Si vous êtes à l'aise avec la ligne de commande, cette méthode vous donne plus de contrôle et s'intègre dans un flux de travail basé sur Git.

Voici le truc avec les sites WordPress : ils sont composés de trois parties distinctes qui doivent toutes être synchronisées séparément.

• Code : les fichiers de votre thème, les plugins et les fichiers principaux de WordPress. C'est ce que Git gère.
• Base de données : tout votre contenu, vos paramètres et vos configurations. Git ne touche pas à cela. Vous avez besoin de WP-CLI.
• Média : tout ce qui se trouve dans votre dossier /wp-content/uploads/. Également pas dans Git. Vous avez besoin de rsync ou d'un outil similaire.

Comprendre cette séparation est la clé. Git seul ne suffira pas.

Le flux de travail pour tirer de la production

Passons en revue comment ramener votre site de production en local.

Pour le code, c'est simple. Si votre thème et vos plugins personnalisés sont dans un dépôt Git, exécutez simplement :

git pull origin main

Votre code local correspond maintenant à la production.

Pour la base de données, SSH dans votre serveur de production et exportez la base de données en utilisant WP-CLI :

wp db export production-backup.sql

Téléchargez ce fichier .sql sur votre machine locale. Ensuite, importez-le localement :

wp db import production-backup.sql

Mais vous n'avez pas encore terminé. Votre base de données contient toujours toutes les URL de production. Vous devez les remplacer par vos URL locales :

wp search-replace 'https://mysite.com' 'http://localhost/mysite'

Cette commande de recherche et remplacement parcourt chaque table et chaque champ, mettant à jour les URL partout où elles apparaissent. Elle gère même correctement les données sérialisées, ce qui est essentiel pour WordPress.

Sautez cette étape, et votre site local essaiera de charger les images de la production, vous redirigera vers le site en direct, et se comportera généralement comme s'il ne savait pas où il se trouve.

Pour les fichiers multimédias, utilisez rsync. Il est conçu pour synchroniser efficacement de grands répertoires.

rsync -avz user@mysite.com:/path/to/wp-content/uploads/ ./wp-content/uploads/

Les indicateurs -avz signifient « mode archive, sortie détaillée, compression pendant le transfert ». Cette commande télécharge uniquement les fichiers qui ont changé, les synchronisations ultérieures sont donc rapides.

Exécutez ces trois étapes (récupérer le code, importer la base de données, synchroniser les médias) et vous obtiendrez une copie locale complète de la production.

Meilleures pratiques pour assurer une synchronisation fluide et sûre

Vous pouvez avoir les meilleurs outils du monde, mais cela n'a pas d'importance si vous les utilisez mal.

J'ai vu des développeurs effacer des bases de données de production parce qu'ils ont poussé alors qu'ils auraient dû tirer. J'ai vu des gens sauter les sauvegardes parce que « ce n'est qu'une synchronisation rapide » et passer ensuite le week-end à récupérer des données.

Ne soyez pas cette personne.

Ces meilleures pratiques peuvent faire la différence entre un flux de travail fluide et une erreur qui met fin à votre carrière.

Sauvegardez toujours d'abord

Avant de synchroniser quoi que ce soit dans n'importe quelle direction, faites une sauvegarde. La seule fois où vous la sautez, quelque chose tournera mal.

Duplicator facilite cela : c'est à la fois un plugin de migration et de sauvegarde. La première étape de chaque migration par poussée ou par tirage sera une sauvegarde complète du site, protégeant ainsi votre site.

Si quoi que ce soit arrive, appuyez sur le bouton Restaurer en un clic.

Ou, téléchargez les deux fichiers de sauvegarde sur le même serveur. Exécutez l'installateur et suivez les instructions de récupération.

Si vous utilisez des outils en ligne de commande, exécutez rapidement wp db export avant de faire quoi que ce soit d'autre.

Cinq minutes de création de sauvegarde peuvent vous faire économiser des jours de travail de récupération.

Tirez vers le bas, poussez le code vers le haut

Voici le flux de travail professionnel standard : tirez la base de données et les fichiers médias de la production vers le local. Ne poussez les modifications de code vers la production que via Git.

Vous ne devriez pousser votre base de données locale vers la production que rarement, à moins que vous ne soyez en train de lancer un tout nouveau site.

Pourquoi ? Parce que la production contient des données réelles qui changent constamment. Si vous écrasez la base de données de production avec votre copie locale, toute cette activité récente disparaît.

Utilisez un environnement de staging

Le flux de travail idéal n'est pas Local » Production. C'est Local » Staging » Production.

Un environnement de staging est une copie de votre site de production qui vit sur un serveur réel mais n'est pas accessible au public. C'est votre terrain de test final avant que les changements ne soient mis en ligne.

Vous développez localement. Ensuite, testez sur staging avec la configuration réelle du serveur et les données de production récentes. Ce n'est qu'après que tout est vérifié sur staging que vous déployez en production.

Cela ajoute un tampon de sécurité. Si quelque chose casse sur staging, aucun utilisateur ne le voit. Vous le détectez et le corrigez avant que cela n'ait d'importance.

Tous les projets n'ont pas besoin de staging, en particulier les petits sites. Mais pour tout ce qui a du trafic réel ou des fonctionnalités de commerce électronique, cela vaut la peine d'être mis en place.

Utilisez un fichier .gitignore

Si vous utilisez Git, vous devez lui indiquer ce qu'il ne faut pas suivre.

Votre fichier wp-config.php contient des identifiants de base de données différents sur chaque environnement. Il ne devrait pas être dans le contrôle de version.

Votre dossier /wp-content/uploads/ peut contenir des gigaoctets d'images et de fichiers. Ceux-ci n'appartiennent pas non plus à Git, c'est à cela que sert rsync.

Créez un fichier .gitignore à la racine de votre dépôt et ajoutez au minimum ceci :

wp-config.php

.htaccess

wp-content/uploads/

*.log

Cela permet de garder votre dépôt propre et vous évite de commettre accidentellement des informations sensibles ou de gonfler votre dépôt avec des fichiers binaires.

Questions fréquemment posées (FAQ)

Perfectionnez votre flux de travail de synchronisation WordPress

Aller au-delà des méthodes manuelles est l'un de ces tournants dans votre carrière de développeur. Vous cessez d'être quelqu'un qui copie des fichiers et croise les doigts. Vous devenez quelqu'un avec un processus.

Un flux de travail répétable — que vous utilisiez un outil comme Duplicator ou que vous exécutiez des commandes dans le terminal — remplace l'anxiété de déploiement par la confiance.

Votre futur moi vous remerciera la prochaine fois que vous devrez tester une fonctionnalité par rapport à de vraies données de production, ou télécharger le dernier contenu, ou déployer sans stress.

Prêt à arrêter de jongler avec les outils en ligne de commande et à vous demander si vous avez manqué une étape ? Duplicator Pro vous offre une boîte à outils complète et fiable pour migrer et sauvegarder votre site.

Créez une sauvegarde complète du site, envoyez-la directement vers le stockage cloud et déployez-la dans un nouvel emplacement avec un installateur simple et guidé qui gère tout le travail acharné. Découvrez Duplicator Pro pour simplifier votre flux de travail dès aujourd'hui !

Pendant que vous êtes ici, je pense que vous aimerez ces autres ressources WordPress triées sur le volet :

• Comment utiliser l'interface de ligne de commande WordPress : maîtrisez la ligne de commande
• Comment déplacer un site WordPress en direct vers un hôte local (La méthode facile)
• Comment déplacer un site WordPress local vers un serveur en ligne
• Codez plus intelligemment, pas plus dur : outils de développement WordPress pour tous les professionnels
• Comment un développeur migre facilement des boutiques en ligne avec 150 000 produits