# On est passés à DDEV, pourquoi ?

Chez BSA Web, on a longtemps eu le débat de l’outil pour travailler en local : *Local by Flywheel*, *Docker*, *Lando*, *MAMP*… Nombreuses sont les options disponibles pour éviter de travailler directement en production. On s’était arrêtés sur Local il y a environ 2 ans. Mais ça, c’était avant de découvrir **DDEV**.

## Local, je t’aime mais…

Nous avions toujours été séduits par [Local](https://localwp.com/) : une jolie interface graphique, la possibilité de lancer un site rapidement, un domaine local facilement identifiable, WP CLI disponible…

Cependant, quelques soucis pouvaient nous gâcher la vie au quotidien :

- L’impossibilité de versionner les environnements précis : Alex pouvait travailler en PHP 8.2, le serveur de préproduction être en 8.3, Benjamin en 8.1… On pouvait travailler avec Apache, Nginx, Maria DB, MySQL… Autant d’options qui nous ont forcément fait perdre un petit peu de temps à certains moments d’un projet.
- Lancer un projet ou créer un projet depuis la CLI était impossible. Ce qui nous obligeait à créer un site depuis l’interface, alors qu’on pourrait le faire en une ligne de commandes. Pour nos développeurs TMA, c’était forcément quelques minutes de perdues plusieurs fois par jour, au moment de reprendre les projets.
- La CLI de WP était installé, mais pour y avoir accès, il fallait lancer le terminal depuis Local, pour avoir accès à l’environnement de Local.
- Quelques problèmes récurrents, signalés sur le forum de Local, mais encore en suspend à ce jour : problèmes de certificats, routeur parfois capricieux…

## Des tests en pagaille

Chez BSA Web, on choisit nos outils avec parcimonie. Avant de faire passer toute l’agence à une nouvelle solution, il fallait être sûr qu’elle réponde à tous les critères que nous nous étions fixés.

Nous ne voulions pas perdre de fonctionnalités par rapport à Local. La seule chose sur laquelle nous étions prêts à faire une croix, c’était l’interface : dans une agence de techs, le terminal ne fait pas peur (la douche non plus, ne vous inquiétez pas 😄).

Nous voulions conserver le domaine facilement identifiable, et éviter le localhost:UN\_PORT\_AU\_HASARD. Cela a donc directement éliminé `wp-env`.

Lando, lui, ne permettait pas d’accéder au site via son adresse `*.lndo.site` si nous étions hors-ligne. Ca n’est pas souvent, mais se retrouver à modifier la configuration d’un site lors d’un trajet pour un WordCamp ou dans le train, sans accès à la documentation, peut vite devenir compliqué et source d’agacement. La configuration nous semblait plus verbeuse également.

Nous avions déjà exploré l’option Docker, mais sans connaissance poussée de l’outil, on a vite détourné le regard : on aurait pu le configurer, mais la moindre modification dans la configuration n’était pas chose aisée pour nous. Notre valeur n’est pas là.

## La découverte : DDEV

À force d’en parler, de fouiner, une solution a retenu notre attention : [DDEV](https://ddev.com/).

Sur le papier, cela comblait tous les problèmes, car cela nous permettait :

- de versionner les environnements, y compris le domaine utilisé, la version de PHP, de MySQL (ou autre) via le fichier `.ddev/config.yaml`
- d’accéder à [WP CLI](https://wordpress.org/cli/) directement depuis le terminal via `ddev wp cli`
- de lancer un site en une ligne de commande : `ddev start` et d’y avoir accès en HTTPS, via `mkcert` (pas de problème d’accès hors-ligne comme Lando).
- De choisir finement notre configuration pour coller au maximum aux environnements de production selon les projets : version de PHP, base de données (MariaDB, PostgreSQL, MySQL sont disponibles), domaine.
- [Compatible avec Bedrock](https://roots.io/bedrock/docs/bedrock-with-ddev/) et une architecture WordPress classique, ce qui est un gros plus, dans un contexte où l’on utilise Bedrock pour nos nouveaux projets, et que l’on récupère des architectures différentes dans le cadre de reprise de projets en maintenance.

Maintenant, il restait un point de friction : comment convertir tous les sites de l’agence rapidement, car le nombre peut très vite monter. En explorant la structure Local, on peut voir que la base de données SQL est contenue dans le site `monsite/app/sql` .

Cela nous a donc permis avec un BASH de migrer l’intégralité de nos sites vers DDEV, dans un temps plutôt correct sur le volume.

## Intégrer DDEV à nos outils en place

Et maintenant, il restait plusieurs outils en place à modifier pour y intégrer DDEV, notamment notre outil de création de projet. On en a profité pour lui donner un petit coup de polish.

Auparavant, nous utilisions un script BASH : plutôt lent, dans un langage que nous connaissons sans pour autant le maîtriser, interface peu reluisante… On a donc migré cela pour une CLI plus globale, écrite en JavaScript, mais on aura l’occasion d’y revenir plus en détails dans un autre article.

Revenons à nos moutons, maintenant nous pouvons choisir l’environnement de développement sur lequel nous souhaitons créer un nouveau projet. À terme, nous déprécierons totalement l’option Local, en supprimant l’option dans la CLI.

## Et après ?

Désormais, il nous reste quelques améliorations à apporter à notre configuration DDEV. Nous avons déjà noté les axes d’amélioration suivants :

- ajouter un hook à l’éxécution de `ddev start` pour créer un .htaccess qui nous permettrait de récupérer les médias directement depuis la prod.
- faciliter les imports de bases de données de la production à notre local, pour travailler avec les données les plus récentes possibles.

Et comme pour tous nos outils internes, à chaque problème, on créera une issue sur notre GitLab, et on améliorera. Comme dirait notre Floflo national : “Pas parfait, c’est mieux que pas fait”.