Why DDEV?

In our Techradar we've listed DDEV as a tool to assess. But why?

Last year, I was doing a bit of "project hopping" to help out here and there. Whilst for our Magento projects, we use a customized version of markshust/docker-magento in most of our other projects, we use the Docker setup we've inherited by the previous agency or set up something custom.

At some point, I was a bit annoyed that each setup was different, and I had to adapt my workflow constantly. I remembered DDEV and thought, why not give it a try? I've never been a fan of adding abstractions over abstractions, but if it helps to have a consistent development setup with Docker, it probably is worth it. Around the same time, the DDEV folks announced supporting Traefik, which for me being a Traefik Amdassador is another plus. I tested DDEV in a first project and began to like it. I introduced it to more and more projects and onboarded our developers. So far, everybody seems to enjoy using it.

But why?

First of all, it's good to have one common interface, aka the DDEV commands to interact with. Starting and stopping DDEV works consistently across all projects. Running package mangers like Composer or NPM via DDEV is exactly the same. Creating and importing database dumps works the same way, regardless of the database used.

Being able to customize the setup, e.g. add custom scripts, add post-install hooks or even add additional docker containers to the stack, is easy.

DDEV allows us to run multiple projects simultaneously since Traefik is running as a "global" service. In our usual project setups, Traefik is part of the project setup, which means running two projects simultaneously is impossible due to port collisions.

But the biggest bonus point for me is the PhpStorm integration. Thanks to the DDEV Integration plugin, the projects get configured automatically. The database connection is created based on the DDEV configuration, and the server and CLI configuration is configured correctly, which simplifies running tools like PHPUnit or Xdebug. Having those things "just" working out-of-the-box is the most significant advantage of our DDEV setup.

Of course, there's a downside: We now deal with separate Docker images for local development and staging/production deployments. We need to ensure all required tools are installed in both setups manually. Not a big showstopper but still something we need to care about. Having two different images for development and deployment might not be ideal for reproducing bugs, but things have worked out fine for us.

Since DDEV is fully customizable, one could potentially let the images used by DDEV inherit from the production Docker images. I might give this a try and see if that route makes sense to go. I'll blog about my findings in another blog post, for sure.