What the craftsmen use for their workshops is the local development environment for our development team. And we want it to be nice and simple and cosy. After all, we have enough other things to think and puzzle about.
When DDEV launches Drupal for you it creates settings.ddev.php files. This file is added as an include to the settings.php file that Durpal generally uses. Scroll to the bottom of your settings.php file and you will see the code that DDEV has had to append there after your first installation. DDEV, Docksal, and Lando's command line tool provide a command to run Drush commands: fin drush, lando drush, ddev exec. Pantheon and other remote host support I tend to use Pantheon quite a bit, both for clients and teaching.
From MAMP/LAMP and Docker to DDEV
In the past, each of our developers had an own MAMP/LAMP setup on his machine. This was easy to set up, worked rather uncomplicated and was also fast. However, over time, more and more problems arose. Among other things, some projects required newer php versions or special server settings that were difficult to reproduce on the local computers. In addition, it became more and more difficult to switch quickly between projects, because you always had to adjust the local configuration of your system.
Run ddev in the terminal to test your installation. Configuring DDEV in our Project To demonstrate the configuring process, I will be taking a demo Drupal 8 project. Run the command ddev list, you can see that there are no running ddev projects. Use Git to clone the repository of the project in which you have to set up DDEV. DDEV is an API-first platform featuring easy-to-use local and cloud tools that seamlessly integrate with other local and cloud-based services to construct your unique development, testing, and production hosting workflow. We build DDEV-Local for local development, and DDEV-Live to host your production site.
For this reason we switched to a Docker-based setup for local development. This made it quite easy for us to reproduce the specifics of the servers on which the websites we were responsible for were located. This way we were better protected against unpleasant surprises after deployments - after all, the local development environment was now almost identical to the live server.
Over time, however, disadvantages of our docker setup became more apparent. It was still quite complicated to set up a new project (you had to copy various files to the right places, overwrite settings, ...). There was also a big weakness compared to the old MAMP/LAMP setup: It was not possible to run multiple projects locally at the same time; at least not without manually overwriting some settings. This finally made us rethink our setup and look for better alternatives. This is how we finally came up with DDEV.
What is DDEV?
DDEV-Local - so the complete name - is an open source based tool for software development. It builds up a local web server with the corresponding software packages, through which code can be easily built, tested and deployed. DDEV is based on Docker, but simplifies the work for the development team enormously and offers additional extensions.
Everything for a simple working environment
With DDEV, the initial setup is easy and done in no time. With only three commands in the command line (git clone, composer install, ddev start) a project is now usually set up locally. Two arguments in particular have convinced us to switch to DDEV:
- Setting up a local project is wonderfully simple and fast.
- We can easily run multiple instances in parallel in the local environment.
As a Drupal agency we work with various customer sites and not every developer has always set up all projects on his machine. With DDEV we now have a significant time saving especially with the changing sprints and security updates. The actual killer feature for us, however, is the parallel operation. During the weekly update evenings we install the latest updates in all our (SLA) customer projects. If every project were to be processed sequentially, our team would hardly be able to manage the updates in one single evening. Thanks to DDEV, we can now easily work on these projects in parallel and don't have to start complex workarounds with Docker. This saves us an enormous amount of time and hopefully long night shifts in the future.
There are other pre-built things for DDEV that simplify the work. For example the command ddev share, which makes the local instance of the page available via a public URL. This is a great way to test local sites on other devices (like the smartphone, tablet).
At https://github.com/drud/ddev-contrib there are a lot of useful examples and templates to extend DDEV. So you can easily add Solr or Varnish to your project setup to be as close as possible to the production environment.
DDEV is already simplifying our daily work enormously now that we are using it in the first projects. The development teams can use Docker functions quickly and easily. And another plus: DDEV is not limited to Drupal. So we can recommend it to anyone who works with php projects and also wants to set up different CMS locally.
Stefan maintains several Drupal contributed modules, has been working on Drupal core since the early days, and is author of Drupal 8 Configuration Management (Packt Publishing).
Most ddev commands provide hooks to run tasks before or after the main command executes. To automate setup tasks specific to your project, define them in the project's config.yaml file.
To define command tasks in your configuration, specify the desired command hook as a subfield to
hooks, then provide a list of tasks to run.
Supported Command Hooks¶
pre-start: Hooks into 'ddev start'. Execute tasks before the project environment starts. Note: Only
exec-hosttasks can be generally run successfully during pre-start. See Supported Tasks below for more info.
post-start: Execute tasks after the project environment has started.
post-import-db: Execute tasks before or after database import.
post-import-files: Execute tasks before or after files are imported
post-composer: Execute tasks before or after the
post-restore-snapshot: Execute as the name suggests.
post-stop: Hooks into 'ddev stop'. Execute tasks after the project environment stopped. Note: Only
exec-hosttasks can be generally run successfully during post-stop.
ddev currently supports these tasks:
execto execute a command in any service/container
exec-hostto execute a command on the host
composerto execute a composer command in the web container
exec: Execute a shell command in a container (defaults to web container)¶
Value: string providing the command to run. Commands requiring user interaction are not supported. You can also add a 'service' key to the command, specifying to run it on the db container or any other container you use.
Example: Use drush to clear the Drupal cache and get a user login link after database import
Example: Use wp-cli to replace the production URL with development URL in the database of a WordPress project
Example: Add an extra database before import-db, executing in db container
Example: Add the common 'll' alias into the web container .bashrc file
Ddev Drupal 7 Drush
(Note that this could probably be done more efficiently in a .ddev/web-build/Dockerfile as explained in Customizing Images.)
exec-host: Execute a shell command on the host system¶
Value: string providing the command to run. Commands requiring user interaction are not supported.
Example: Run 'composer install' from your system before starting the project (composer must already be installed on the host workstation):
composer: Execute a composer command in the web container¶
Value: string providing the composer command to run.