DDEV est un outil qui facilite le développement Web local en permettant d’avoir rapidement accès à un environnement. Il a été créé pour aider les développeurs à travailler sur leurs projets de manière efficace et productive. Plus besoin de chercher les informations concernant le projet (version de PHP, serveur utilisé sur l’environnement de production, version de node, librairies nécessaires, etc.).
DDEV est basé sur Docker, une plateforme de virtualisation de conteneurs qui permet d'isoler les applications dans des conteneurs légers et portables. Cette approche permet aux développeurs de travailler avec des environnements de développement isolés, sans risque d'interférer avec d'autres projets ou avec le système d'exploitation de l'ordinateur hôte.
Facile à installer et à utiliser, il suffit de créer un fichier de configuration YAML pour définir les paramètres du projet afin que l’image appropriée soit téléchargée. On peut spécifier les modules et/ou les services nécessaires et ils seront ajoutés à l’environnement. Au besoin, des commandes peuvent être exécutées suite au démarrage.
Pour installer DDEV, il faut d’abord installer Docker. Vous pouvez suivre les instructions d’installation de la documentation. Une fois terminé, exécutez la commande ddev -v pour valider que DDEV est fonctionnel.
Pour développer un site en utilisant DDEV, il faut d’abord générer la configuration initiale en exécutant la commande ddev config.
Vous devrez ensuite répondre à trois questions. À chacune d’elle, DDEV proposera une valeur selon le projet. Si elle convient, appuyez sur la touche “Entrée” pour la valider et passer à la prochaine question. Sinon, inscrivez la valeur désirée.
Un fichier sera créé dans .ddev/config.yaml. Révisez la configuration en vous référant à la section «Configuration» de cet article. Une fois complétée, exécutez la commande ddev start afin de démarrer l’instanciation du conteneur. Si tout se passe bien, l’URL du site sera affichée et accessible dans un navigateur. Il faut par contre exécuter quelques manipulations supplémentaires avant d’avoir un site fonctionnel.
Nous utilisons habituellement la base de données de l’environnement de développement lorsque nous développons en local1. Pour se connecter à celle-ci, nous devons conserver les mêmes fichiers de configuration par défaut, selon le CMS en place :
WordPress: wp-config.php
Définir les constantes WP_HOME et WP_SITEURL pour https://globalia.ddev.site
Craft 3 | Laravel: .env
Craft 2: craft/config/db.php et craft/config/general.php
Il est recommandé d’activer l’option suivante pour éviter que DDEV n’écrase constamment les valeurs du fichier de configuration de l’environnement (wp-config.php, .env) → disable_settings_management: true.
Attention: souvent, l’alias db est attribué pour le host. Cette valeur est déjà utilisée par DDEV, ce qui causera des soucis de connexion. Il faut donc soit changer d’alias, soit inscrire l’adresse IP interne directement.
Pour installer les dépendances front-end et back-end, nous devons entrer dans le conteneur. Pour ce faire, exécutez ddev ssh.
Vous pouvez valider la version de node avec la commande node -v. Elle devrait être la même que celle que vous avez spécifiée dans le fichier de configuration. Vous pourrez exécuter groots install ou npm install, selon le projet pour installer les dépendances front-end. Par la suite, assurez-vous qu’un gulp initial s’exécute sans erreur. Les dépendances en node 6 entraîneront souvent des problèmes de certificat SSL, auquel cas vous devrez probablement mettre à jour à la version 10.
Côté back-end, les bonnes versions de PHP (php -v) et de composer (composer -V) seront sélectionnées. Il suffira de se rendre où se situe le composer.json pour exécuter composer install.
Il ne reste plus qu’à tester en visitant le site. Il est possible que des redirections ou des instructions supplémentaires soient nécessaires au bon fonctionnement. Consultez la section «Serveur» du présent article pour davantage de détails.
Si tout est fonctionnel, vous pouvez versionner le fichier de configuration dans le .git.
1 - Cela dépend bien sûr du projet, car parfois il est préférable d’avoir sa propre base de données locale (surtout si on fait beaucoup de tests). Voir la section Base de données locale de cet article pour plus d’informations à ce sujet.
Plusieurs paramètres peuvent être configurés dans le fichier config.yaml afin d’obtenir l’environnement de développement souhaité. Celui-ci doit refléter le plus fidèlement possible l’environnement de production.
name: globalia
type: wordpress
docroot: wordpress
php_version: "7.4"
webserver_type: nginx-fpm
router_http_port: "80"
router_https_port: "443"
xdebug_enabled: false
additional_hostnames: []
additional_fqdns: []
database:
type: mariadb
version: "10.3"
nfs_mount_enabled: false
mutagen_enabled: false
use_dns_when_possible: true
composer_version: "1"
web_environment: []
disable_settings_management: true
omit_containers: [db, dba, ddev-ssh-agent]
webimage_extra_packages: [build-essential, python2, libgl1, libxi6]
hooks:
post-start:
- exec-host: "ddev nvm install 10"
- exec-host: "ddev nvm use 10"
Les commentaires se trouvant au bas de ce fichier indiquent quels paramètres peuvent être modifiés et comment.
Parfois, il est préférable d’avoir sa propre base de données locale, surtout si on fait beaucoup de tests. Il suffit d’avoir un dump (fichier) de la base de données pour l’importer avec la commande ddev import-db. Assurez-vous de ne pas omettre db (et dba si vous voulez PHPMyAdmin) de l’option omit_containers. Toutes les informations demandées pour se connecter (DB_NAME, DB_USER, DB_PASSWORD et DB_HOST) doivent avoir la valeur db. Il est également possible d’exporter la base de données avec la commande ddev export-db.
mkcert est un outil simple permettant de créer des certificats de développement local valides. Il ne nécessite aucune configuration. Voici les grandes lignes selon votre système d'exploitation.
Avant de procéder, il faut fermer tout logiciel d’édition de code (PHPStorm, VS Code). Exécutez ensuite la commande wsl shutdown
Vous avez deux options:
sudo apt install libnss3-tools
curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
chmod +x mkcert-v*-linux-amd64
sudo cp mkcert-v*-linux-amd64 /usr/local/bin/mkcert
mkcert -install
Il suffit de l’initialiser une seule fois avec la commande suivante :
mkcert -install
Quelques manipulations additionnelles sont nécessaires afin de développer dans un site WordPress dont la fonctionnalité multisite est activée.
Dans les explications suivantes, le site “Mon Site” sera pris en exemple en utilisant la base de données de l’environnement de développement.
Pour indiquer la route d'accès vers notre nouvel environnement de développement, il faut rediriger les domaines des sites (de la table site) vers le poste local. Cela se fait en éditant le fichier hosts, se trouvant ici :
Windows : C:\Windows\System32\drivers\etc\hosts
Mac et Linux : /etc/hosts
Vous pouvez inscrire tous les sites sur une seule ligne ou en plusieurs :
127.0.0.1 monsite.globaliadev.com soussite-monsite.globaliadev.com
Il faut également les ajouter dans l’option additional_fqdns:
additional_fqdns: [monsite.globaliadev.com,
soussite-monsite.globaliadev.com]
Des rewrites sont également nécessaires. Si le serveur est nginx, créer le fichier wordress_multisite.conf sous .ddev/nginx :
if (!-e $request_filename) {
rewrite ^(/[^/]+)?(/wp-.*) $2 break;
rewrite ^(/[^/]+)?(/.*\.php) $2 break;
}
Si le serveur est apache, le .htaccess au docroot devrait contenir les instructions nécessaires. En voici un exemple :
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
Si vous travaillez sur un ou plusieurs autres anciens projets, il est possible qu’Apache soit déjà en cours d’exécution sur votre poste. Celui-ci doit être arrêté avant de pouvoir lancer ddev, car il écoute sur le port 443 pour les requêtes https. Pour ce faire, exécuter :
sudo systemctl stop apache2
Parfois, des configurations supplémentaires (comme des rewrite) sont nécessaires pour les sites exécutés sous nginx. DDEV lit automatiquement tous les fichiers se terminant par .conf dans le dossier nginx (que vous devez créer).
Par exemple, des rewrites sont nécessaires pour les multisites WordPress "Mon Site”. Sous .ddev/nginx, le fichier wordress_multisite.conf:
if (!-e $request_filename) {
rewrite ^(/[^/]+)?(/wp-.*) $2 break;
rewrite ^(/[^/]+)?(/.*\.php) $2 break;
}.
Lorsque le développement est terminé, il est fortement recommandé d’arrêter le conteneur en exécutant ddev stop afin de libérer les ressources.
Le débogage est simple avec l’outil xdebug. Il est installé par défaut dans le conteneur, mais pour des raisons de performances, il est désactivé par défaut. On peut l’activer au démarrage dans la configuration (config.yaml) ou en exécutant la commande ddev debug (valeur on par défaut) dans le terminal. Pour le désactiver, ddev xdebug off.
Dans PHPStorm, il suffit d’activer Run / Start Listening for PHP Debug Connections pour que les points d’arrêt soient pris en compte lors du chargement du site. La barre de débogage apparaîtra en bas à gauche.
Si vous développez avec PHPStorm, l’installation du plugin DDEV Integration vous permettra d’utiliser les fonctionnalités de DDEV à même celui-ci. Entre autres, vous pourrez ouvrir le conteneur DDEV afin d’y exécuter des commandes, profiter des suggestions pour la configuration et plus encore.
Côté courriels, DDEV est idéal pour le développement, car aucun ne sort du conteneur. En effet, ils sont interceptés par MailHog. On ne risque donc pas d’envoyer par mégarde des courriels lors de tests sur cet environnement.
Pour consulter les courriels, on peut exécuter ddev launch -m.
On peut également connaître l’URL en exécutant ddev status. Un port est ajouté à l’URL du site Web (ex. : https://globalia.ddev.site:8026).
ddev: Liste des commandes disponibles
ddev debug on|off: Active ou désactive xdebug
ddev launch: Ouvre le site Web dans un navigateur
ddev launch -m: Ouvre la boîte de courriels dans un navigateur
ddev list: Affiche tous les projets sous DDEV ainsi que leur statut
ddev logs: Consulter l’historique des erreurs
ddev poweroff: Arrête tous les projets et les conteneurs
ddev restart: Redémarre le conteneur (nécessaire lors d’une modification dans la configuration)
ddev ssh: Permet d’entrer dans le conteneur
ddev status: Liste les services ainsi que leur statut pour le site où la commande est exécutée
ddev start: Démarre le conteneur
Besoin d'un coup de main avec cette manipulation ou intéressé à joindre une équipe de passionnés? Nancy, notre développeuse back-end et l'autrice de cet article peut te venir en aide. Contact-nous!