Développer en local a longtemps reposé sur des environnements fragiles : installations manuelles, configurations obsolètes ou encore outils propriétaires qui introduisent une couche d’abstraction parfois limitante. Ces solutions partagent un défaut majeur : le manque de cohérence entre les environnements mais également entre les développeurs.
DDEV, basé sur Docker, résout ces problèmes d’une manière unique et élégante. En "conteneurisant" l’ensemble de la stack, DDEV permet de définir une configuration identique sur n’importe quel poste. Celle-ci est versionnable via Git et donc facile à partager entre membres d’une équipe. Fini les "ça marche sur ma machine", place à une stack commune et totalement flexible pour ajouter des services complémentaires si nécessaires.
Dans cet article, nous allons aborder en détails les fondements de DDEV : pourquoi adopter les containers, quels services sont montés par défaut, comment étendre l’outillage via les addons, et en quoi DDEV se distingue de son principal concurrent Lando.
La base de tout projet informatique est d’avoir une configuration la plus similaire possible entre les différents environnements (développement, préproduction, production) afin de maximiser la compatibilité du code entre chacun.
Les développeurs avec un minimum d’expérience le savent, les stacks LAMP traditionnelles (Linux, Apache, MySQL, PHP) installées directement sur la machine hôte posent plusieurs problèmes structurels. Chaque projet nécessite une configuration spécifique (version de PHP, extensions activées, configuration Apache), véritable porte d’entrée pour de futurs conflits. D’autres outils comme MAMP, XAMPP ou Local by Flywheel simplifient l’installation initiale, mais au détriment de la personnalisation et l’évolutivité des projets locaux.
Plus problématique encore, l’impossibilité de garantir que l’environnement de développement corresponde exactement à celui de production. Un développeur travaille sur PHP 8.1, un autre sur PHP 8.2, le serveur de staging tourne sur PHP 8.3... Chaque machine détient sa propre configuration, et les c’est le début des ennuis
Docker résout ces problèmes en isolant chaque partie du projet dans ce que l’on appelle des containers, des environnements légers et reproductibles qui garantissent l’homogénéité des outils utilisés. Un container Web exécute Nginx et PHP-FPM, un autre héberge MySQL, un troisième gère Redis...
Chaque service est isolé (n’impactant donc pas la machine locale en elle-même), mais communique via un réseau virtuel interne. Pour une plongée en profondeur sur les containers, n’hésitez pas à vous référez à notre article Container, the hard way : un voyage à travers la complexité des conteneurs.
DDEV orchestre ces containers automatiquement. Une simple commande ddev start lance l’ensemble de la stack définie dans la configuration. Le fichier .ddev/config.yaml versionné dans Git garantit que tous les développeurs travaillent dans des conditions identiques, éliminant de facto les configurations divergentes selon le poste de chaque développeur.
DDEV promet donc beaucoup de choses. Mais par où commencer ? Faisons ensemble un tour d’horizon des fichiers et commandes à connaître.
Dans DDEV, la plupart des configurations de base s’effectuent via un fichier en particulier : .ddev/config.yaml, à la racine de votre répertoire.
C’est ici que nous allons gérer grâce à un seul fichier :
Bref, tout le squelette de notre projet local. En voici un exemple :
name: bittersweet
type: symfony # ou laravel, drupal, wordpress etc.
docroot: public # à définir selon l’architecture du type de projet
php_version: "8.4"
webserver_type: nginx-fpm # ou apache
xdebug_enabled: false # définit si xdebug est activé par défaut au lancement
additional_fqdns: # les éventuels sous-domaines nécessaires
- tickets.bittersweet.ddev.site
- shop.bittersweet.ddev.site
database:
type: mariadb
version: "10.11"
composer_version: "2"
Tout est donc entièrement configurable en éditant le fichier yaml, il suffira ensuite de relancer DDEV pour que la configuration prenne effet.
DDEV propose un ensemble de "quickstarts", qui permettent de générer ce fichier automatiquement selon la typologie de projet que vous souhaitez utiliser : https://docs.ddev.com/en/stable/users/quickstart/
Toute la gestion du cycle de vie de votre projet avec DDEV sera ensuite gérée via le terminal. Voici une liste, non-exhaustive, des commandes de base à connaître :
.ddev/ et du .envVous pouvez retrouver l’intégralité des commandes DDEV à cette adresse : https://docs.ddev.com/en/stable/users/usage/commands/
Un container peut être visualisé comme une "boîte" qui embarque une application et ses dépendances et vit en autarcie. DDEV orchestre plusieurs containers spécialisés qui communiquent via un réseau Docker interne.
Le container Web héberge Nginx et PHP-FPM. C’est ici que sera exécuté votre code. Nginx sert les fichiers statiques et transmet les requêtes PHP à PHP-FPM pour exécution. Au besoin, vous pouvez accéder à ce container via ddev ssh pour inspecter les logs, modifier des fichiers ou exécuter des commandes PHP directement.
Le container db exécute MySQL (ou MariaDB selon configuration). DDEV expose ce service sur localhost:3306 pour permettre la connexion depuis des clients SQL externes (DBeaver, si installé localement, est par exemple accessible via la commande ddev dbeaver). La base de données persiste entre les redémarrages via un volume Docker, évitant toute perte de données.
DDEV intègre Mailpit, un mail catcher qui intercepte tous les emails sortants. Accessible via ddev launch -m, il permet de tester l’envoi d’emails (réinitialisation de mot de passe, notifications) sans risquer d’envoyer de vrais emails en développement. Ces mails sont alors consultables dans une interface Web dédiée.
Afin de ne pas se limiter à une configuration basique, DDEV dispose de tout un écosystème d’addons, consultables depuis le DDEV Add-on Registry : https://addons.ddev.com/
Si vous ne souhaitez pas installer DBeaver sur votre machine, DDEV propose deux addons pour administrer la base de données graphiquement. Il suffit de lancer les deux commandes suivantes depuis une console ouverte sur votre projet :
ddev get ddev/ddev-adminer
ddev get ddev/ddev-phpmyadmin
Adminer est plus léger (un seul fichier PHP), phpMyAdmin offre plus de fonctionnalités avancées. Les deux s’installent comme de nouveaux containers et sont accessibles via la commande ddev launch -p (phpMyAdmin) ou ddev launch -a (Adminer).
Pour les projets nécessitant une recherche performante (sites e-commerce, annuaires, archives), les addons Elasticsearch ou la version open-source OpenSearch s’intègrent en une commande :
ddev get ddev/ddev-elasticsearch
# ou
ddev get ddev/ddev-opensearch
DDEV configure automatiquement le service et l’expose sur un port local. Votre code peut alors se connecter via l’URL fournie (typiquement http://elasticsearch:9200 depuis le container Web). Cette approche simplifie drastiquement la mise en place d’architectures de recherche complexes.
L’addon Redis transforme les performances d’une application en ajoutant une couche de cache en mémoire.
ddev get ddev/ddev-redis
Une fois connecté à votre application, il stocke en RAM les résultats de requêtes coûteuses. Cela permet d’améliorer considérablement les performances de sites à haut trafic ou aux requêtes complexes. DDEV configure encore une fois Redis automatiquement et le rend accessible au container Web via le hostname redis.
DDEV n’est évidemment pas le seul outil disponible sur le marché et destiné à faciliter la conteneurisation d’un projet. Nous abordons très rapidement ici l’exemple de Lando.
Lando propose une approche similaire à DDEV, c’est un autre gestionnaire de containers Docker pour le développement local. Également basé sur des fichiers de configuration YAML (.lando.yml), il supporte lui-aussi WordPress, Drupal, Laravel et autres frameworks. Lando offre une flexibilité importante avec des "recipes" préconfigurées et des services personnalisables.
DDEV présente plusieurs avantages décisifs. Sa configuration est plus intuitive et moins verbeuse que celle de Lando. Les performances sont généralement meilleures, notamment sur macOS où DDEV optimise le partage de fichiers via Mutagen. L’écosystème d’addons officiels est enfin plus mature et souvent mieux documenté.
Surtout, DDEV bénéficie d’une communauté particulièrement active et d’une documentation exhaustive. Les mises à jour sont fréquentes et les bugs corrigés rapidement. Après plusieurs années à utiliser Lando, ces arguments ont convaincu les équipes techniques d’Adimeo de passer sous DDEV.
En résumé, DDEV n’est donc pas un simple outil de plus, c’est un changement de paradigme. Il enferme dans le passé les différences d’environnements entre développeurs et permet d’aligner facilement son projet local avec les environnements de staging ou production.
Pour tout type de projet, l’initialisation, l’import des bases de données et le debug deviennent des opérations triviales et reproductibles par tout développeur, peu importe son expérience. Un fichier de configuration unique mais très paramétrable assurera des environnements de travail homogènes à vos équipes, en l’incluant dans votre politique de versionning Git.
Chez Adimeo, nous sommes persuadés qu’un projet Web réussi se construit à travers une chaine de livraison robuste, de l’environnement local jusqu’à la production. Cela vous semble évident à vous aussi ? Alors n’hésitez pas à nous contacter pour définir ensemble une architecture moderne et sécurisée pour vos projets. 😉
Crédit photo : Pressmaster