What is ddev?
If you're already confident with your web development process or your
already happily using docker in one or the other way - this might not be much of a benefit for you.
But, if you do not use docker at all or don't know where to start or just want to spice (speed) things up a notch, then read on.
ddev lets you focus more on your code and less on dev-ops.
I used to set-up my web development projects directly on my Ubuntu-driven machine with apache's v-hosts. I had a bash-script in place which created a new directory, git repo and added a new host.
But, this had some flaws and required manual steps afterwards pretty often. In short, it got time-consuming to maintain the custom set-up script and all the changes that were made to my system... With more and more projects my time got short and I hesitated to try and learn something thats new to me like docker.
At that time, at my workplace we all used MacBooks for development while personally I am more of a Linux guy. The solution of my workplace (MAMP) was not applicable for my personal projects.
Gladly, I changed workplaces the right time and I got introduced to a new way of how to work on web development project: ddev.
Using plain docker for web development would require you to either use a pre-made image or build one for your self.
If you don't have special needs and only need the general stuff like php, apache and mysql, then you can save yourself some time by not re-inventing the wheel and just using ddev which comes with a pre-defined image.
And it gives you even more:
- Ease of choice for software and versions
- Mailhog for catching emails
- Local SSL support
- Redis support (optional)
- Elasticsearch support (optional)
- Ngrok support optional
Despite that I am mostly working on Laravel projects, I prefer to use ddev because it is not limited to Laravel rather than being universal for web development. With it you can run almost anything. E.g. sometimes I need to spin up a wordpress, which is just a piece of cake with ddev. Having to learn one tool instead of two or more, already validates my choice.
If you don't have docker installed, do so by following these steps.
Afterwards, continue with the docker post-installation steps.
Finally, head to the ddev installation manual and take all the required steps.
Verify your installation with
To run any (existing) project with ddev, just head to the projects root-directory and type
ddev config which starts the initialization process. It asks you for some specifics. Afterwards you can start the container by typing
ddev start. You should be able to reach the project in your browser.
To use xDebug with ddev you have to set it up once. Each time you want to debug wit xdebug you have to start your debugging session with
ddev xdebug. When you're done, stop it via
ddev xdebug false.
To make xDebug in PhpStorm work, you have to set path-mappings in the project debug settings. For example, all my project live in the path ~/Sites/. For a project with ddev, you have to add a path mapping from ~/Sites/laravel-tinker/ to /var/www/html.
Go to Run > Edit Configurations and Add a new Configuration. Here is a screenshot of a working configuration.
The setup process for VSCode is very easy. Go to the ddev documentation and download the provided config snippet.
If your're having troubles, check the ddev and xdebug version. From ddev v1.19.0 the default port for xdebug to listen on is 9003.
For my daily work, I found these commands as my most-used one. You can check out even more commands here.
Add ddev to a project
Start a project
Opens the main project url
Get information about the container, like URLs and local credentials
When you change a PHP version or MySql version, you have to rebuild the container.
-O: Omit/skip database snapshot
-R: Remove stored project data (MySQL, logs, etc.)
ddev stop -O -R && ddev start
Starts a shell session in the container. Requires you to authenticate if your key is password protected. Useful if the container needs to access remote resources, e.g. when you're running a deployment.
ddev auth ssh
(Laravel only) gives direct access to the Laravel artisan CLI
ddev artisan <command>
ddev xdebug ddev xdebug false
Execute any command inside the container, example:
ddev exec <command> ddev exec npm run dev
ddev makes it easy for you to define custom commands. For almost every project I work on, I use a custom command called "provision" for set-up instructions. In here, all steps needed to set up the project are bundled.
Another use-case for a custom command:
# .ddev/commands/web/codequality #!/bin/bash ## #ddev-generated ## Description: Ensure code-quality ## Usage: codequality ## Example: "ddev codequality" cd frontend node_modules/.bin/eslint --ext .js,.vue --fix --ignore-path .gitignore --max-warnings 0 . ## run cs-fixer vendor/bin/php-cs-fixer fix ## run tlinter vendor/tightenco/tlint/bin/tlint ## run phpstan vendor/bin/phpstan analyze -c phpstan.neon composer outdated --ansi -D -m --strict
Okay, until here, all the stuff was pretty basic. Let's tackle something more interesting. Say, we have multiple projects which we're working on, e.g. an API service that we need to call from another app.
You can just start both projects with ddev and work on them. But by default, they can't reach each other. For that, we have to use custom services and define the address where each project will be exposed to. Read about this feature in the ddev documentation.
To make a project accessible for other projects, define a yaml-file like this:
# .ddev/docker-compose.router.yaml version: '3.6' services: web: external_links: - ddev-router:taskdoc.local.ddev.site
That's it, folks.
Leave me a comment and maybe questions and I'll try to help :)
Hope you find this useful!