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

Lorsque votre environnement de développement local ne correspond pas à votre serveur de production, vous codez pratiquement à l'aveuglette.

Vous pensez peut-être que tout fonctionne. C'est probablement le cas, sur votre ordinateur. Mais ce n'est pas là que ça compte.

Disposer d'un processus fiable pour synchroniser le développement local avec la production n'est pas seulement un plus. C'est ce qui distingue les professionnels de ceux qui croisent les doigts à chaque déploiement.

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

En voici les principaux enseignements :

• La synchronisation des environnements élimine les problèmes de compatibilité et détecte les bogues avant que les utilisateurs ne les remarquent.
• Vous pouvez utiliser Duplicator pour un flux de travail de synchronisation locale adapté aux débutants ou GitHub + WP-CLI pour le contrôle en ligne de commande.
• Toujours extraire la base de données de la production et ne pousser que les modifications de code afin d'éviter d'écraser les données en direct.
• Les sites WordPress comportent trois éléments à synchroniser : le code (Git), la base de données (WP-CLI) et les fichiers multimédias (rsync).
• Effectuez toujours une sauvegarde avant de synchroniser quoi que ce soit, utilisez des environnements de test pour effectuer des essais et conservez un fichier .gitignore correct.

Table des matières

Pourquoi synchroniser vos environnements locaux et de production ?

Vous pourriez probablement vous passer de la synchronisation des environnements. Beaucoup de gens le font. Ils doivent simplement composer avec des bugs occasionnels, des problèmes de production aléatoires qui ne se sont pas produits localement et une incertitude persistante chaque fois qu'ils publient une mise à jour.

Mais pourquoi s'infliger ça ?

La synchronisation de vos environnements locaux et de production élimine de nombreux problèmes. Voici ce que vous obtenez réellement en le faisant correctement.

Détectez les erreurs avant leur mise en ligne

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

C'est plus important 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 détectez depuis votre bureau, et non devant les utilisateurs. C'est ce qui fait la différence entre un inconvénient mineur et un véritable problème.

Un bac à sable réaliste pour les tests

Les tests effectués à partir de données fictives sont suffisants pour créer les 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 comportent des cas particuliers é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 à partir de la production vous fournit les publications, les utilisateurs et les produits réels avec lesquels votre code interagira. Vous n'avez plus à faire de suppositions, vous testez en conditions réelles.

Aucun problème de compatibilité

Tous les développeurs ont déjà dit au moins une fois « Mais ça marchait sur mon ordi ». C'est devenu un peu un mème maintenant.

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

Ce genre de confiance change votre façon de travailler. Vous cessez de remettre en question chaque déploiement.

Améliorer la collaboration au sein de l'équipe

Lorsque vous travaillez seul, vous pouvez vous permettre d'avoir un processus désordonné. Ajoutez un deuxième développeur à l'équation, et les choses se compliquent rapidement.

Un processus de synchronisation cohérent signifie que tout le monde part de la même base. Vous effectuez tous vos tests à partir de 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 ne sait laquelle est la plus proche de la production. Ce n'est pas de la collaboration, c'est du chaos.

Comment synchroniser votre environnement local avec la production

Vous pouvez le faire manuellement. Exportez la base de données via phpMyAdmin, téléchargez-la, importez-la localement, puis recherchez et remplacez manuellement toutes les URL dans le fichier SQL. Ensuite, connectez-vous à votre serveur via FTP, compressez le dossier uploads, téléchargez-le, extrayez-le localement...

Je suis épuisé rien qu'à taper ça.

Les méthodes manuelles sont fastidieuses et risquées. Si vous oubliez de remplacer une URL, votre site local commence à pointer vers les ressources de production. Si vous oubliez de mettre à jour correctement un tableau sérialisé, vous corrompez votre base de données.

Il existe une meilleure solution. Voici comment synchroniser vos environnements de développement et de production locaux :

• Duplicator: plugin de migration avec remplacement automatique des URL et installateurs guidés, idéal 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.

Synchronisez les sites locaux et de production avec Duplicator

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

Duplicator crée un instantané complet de votre site et vous fournit un programme d'installation qui gère automatiquement toutes les parties délicates. Vous n'aurez plus à vous soucier du remplacement manuel des URL ou des casse-tête liés à la configuration de la base de données.

Passage de la production au niveau local (flux de travail courant)

C'est ce que vous ferez le plus souvent. Vous souhaitez récupérer l'état actuel de votre site en ligne et travailler dessus 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 une capture instantanée de l'ensemble de votre site à ce moment précis.

La création de la sauvegarde prend quelques minutes, selon la taille de votre site. Une fois terminée, vous disposerez de 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.

Accédez maintenant à votre environnement local. Créez un répertoire vide à l'emplacement où vous souhaitez enregistrer votre copie locale. Placez les deux fichiers (l'archive et le programme d'installation) dans ce répertoire vide.

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

L'assistant vous guide tout au long du processus de connexion à votre base de données locale et gère automatiquement tous les remplacements d'URL.

Il sait que votre site de production se trouvait à l'adresse https://mysite.com et que votre site local se trouve à l'adresse http://localhost/mysite. Il corrige toutes les références dans la base de données sans que vous ayez à intervenir.

Cinq minutes plus tard, vous disposez d'une copie locale parfaite de votre site de production.

Passer de l'environnement local à l'environnement de production

Ce workflow fonctionne dans le sens inverse. Vous prenez votre site local et le déployez en production.

Soyez prudent ici. Cette opération ne concerne en réalité que les lancements de nouveaux sites ou les refontes complètes. Si vous disposez d'un site en ligne avec des utilisateurs actifs, vous ne devriez probablement pas procéder ainsi. Vous écraseriez leurs publications, commentaires et commandes récents.

Si vous devez transférer le code local vers la production, le processus est similaire, mais inversé.

Tout d'abord, et je ne le répéterai jamais assez, sauvegardez intégralement 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échargez les deux fichiers de sauvegarde sur votre serveur de production via FTP ou glissez-déposez l'archive dans la page Importation.

Encore une fois : ne procédez ainsi que si vous êtes certain de vouloir remplacer complètement la production. Pour pouvoir facilement annuler toute modification imprévue, veillez à définir un point de restauration.

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

Synchronisez 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 offre plus de contrôle et s'intègre dans un flux de travail basé sur Git.

Voici ce qu'il faut savoir à propos des sites WordPress : ils sont composés de trois parties distinctes qui doivent toutes être synchronisées séparément.

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

Il est essentiel de comprendre cette distinction. Git seul ne suffit pas.

Le flux de travail pour extraire des données de la production

Voyons comment ramener votre site de production au niveau local.

Pour le code, c'est simple. Si votre thème et vos plugins personnalisés se trouvent dans un dépôt Git, il suffit d'exécuter :

git pull origin main

Votre code local correspond désormais à la production.

Pour la base de données, connectez-vous via SSH à votre serveur de production et exportez la base de données à l'aide de WP-CLI :

wp db export production-backup.sql

Téléchargez ce fichier .sql sur votre ordinateur local. Importez-le ensuite 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 toutes les tables et tous les champs, 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.

Si vous ignorez cette étape, votre site local tentera de charger les images depuis la production, vous redirigera vers le site en ligne 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 les répertoires volumineux.

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 ne télécharge que les fichiers qui ont été modifiés, ce qui accélère les synchronisations suivantes.

Exécutez ces trois étapes (extraire 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 garantir une synchronisation fluide et sécurisée

Vous pouvez avoir les meilleurs outils au monde, mais cela ne sert à rien si vous ne les utilisez pas correctement.

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 des sauvegardes parce que « ce n'est qu'une synchronisation rapide », puis passer le week-end à récupérer des données.

Ne soyez pas cette personne.

Ces bonnes pratiques peuvent faire la différence entre un déroulement harmonieux du travail et une erreur qui mettrait fin à votre carrière.

Toujours commencer par la sauvegarde

Avant de synchroniser quoi que ce soit dans quelque sens que ce soit, effectuez une sauvegarde. Si vous ne le faites pas, quelque chose finira par mal tourner.

Duplicator facilite cette tâche : c'est à la fois un plugin de migration et de sauvegarde. La première étape de toute migration push ou pull consiste à effectuer une sauvegarde complète du site afin de le protéger.

Si quelque chose se produit, cliquez sur le bouton « Restaurer » en un clic.

Ou bien, téléchargez les deux fichiers de sauvegarde sur le même serveur. Lancez le programme d'installation et suivez les instructions de récupération.

Si vous utilisez des outils en ligne de commande, exécutez rapidement wp db export avant toute autre chose.

Cinq minutes consacrées à la création d'une sauvegarde peuvent vous épargner plusieurs jours de travail de restauration.

Tirez vers le bas, poussez le code vers le haut

Voici le processus de travail standard : transférez la base de données et les fichiers multimédias de la production vers votre ordinateur local. Ne transférez les modifications de code vers la production que via Git.

Vous ne devriez que rarement transférer votre base de données locale vers la production, sauf si vous lancez un tout nouveau site.

Pourquoi ? Parce que la production dispose de 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îtra.

Utilisez un environnement de test

Le flux de travail idéal n'est pas Local » Production. Il s'agit plutôt de Local » Préproduction » Production.

Un environnement de test est une copie de votre site de production qui réside sur un serveur réel, mais qui n'est pas accessible au public. Il s'agit de votre dernier terrain d'essai avant la mise en ligne des modifications.

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

Cela ajoute une marge de sécurité. Si quelque chose ne fonctionne pas correctement lors de la mise en place, aucun utilisateur ne le verra. Vous pouvez le détecter et le corriger avant que cela ne devienne un problème.

Tous les projets ne nécessitent pas une mise en scène, en particulier les petits sites. Mais pour tout ce qui concerne le trafic réel ou les fonctionnalités de commerce électronique, cela vaut la peine de la mettre en place.

Utilisez un fichier .gitignore

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

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

Votre dossier /wp-content/uploads/ peut contenir plusieurs gigaoctets d'images et de fichiers. Ceux-ci n'ont pas non plus leur place dans Git : c'est à cela que sert rsync.

Créez un fichier .gitignore à la racine de votre référentiel et ajoutez-y au minimum les éléments suivants :

wp-config.php

.htaccess

wp-content/uploads/

*.log

Cela permet de garder votre référentiel propre et vous évite de valider accidentellement des informations sensibles ou de surcharger votre référentiel avec des fichiers binaires.

Foire aux questions (FAQ)

Perfectionnez votre flux de travail de synchronisation WordPress

Aller au-delà des méthodes manuelles est l'un des tournants décisifs 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 qui suit un processus.

Un workflow reproductible, que vous utilisiez un outil tel que Duplicator ou que vous exécutiez des commandes dans le terminal, remplace l'anxiété liée au déploiement par la confiance.

Votre futur vous remerciera la prochaine fois que vous aurez besoin de tester une fonctionnalité sur des données de production réelles, de télécharger le dernier contenu ou de déployer sans aucun stress.

Vous en avez assez de jongler entre les outils en ligne de commande et de vous demander si vous n'avez pas oublié 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 de votre site, envoyez-la directement vers un espace de stockage cloud et déployez-la vers un nouvel emplacement grâce à un programme d'installation simple et guidé qui se charge de toutes les tâches fastidieuses. 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 WordPress CLI : Maîtriser la ligne de commande
• Comment déplacer un site WordPress vers un hébergeur local (en toute simplicité)
• Comment déplacer un site WordPress local vers un serveur live
• Coder plus intelligemment, pas plus difficilement : Les outils du développeur WordPress pour tous les professionnels
• Comment un développeur migre facilement des boutiques en ligne de 150 000 produits