If you work with PHP, you have a wide range of technologies and systems at your disposal that you can use. PHP has been around for over twenty years, so the tools available to developers today are appropriately diverse. However, some of these options have meanwhile become outdated, while others are quite complicated. On top of that, what was once useful to us at work can prove to stand in our way today. Currently, developers can freely choose from a variety of tools. However, if each person on the team uses different tools, we create our own pitfalls which lead to time wasted on things like configuration or compatibility.
Diversity brings challenges
I’d like now to share a few examples from my own experience with PHP-based open source projects and agencies for which DDEV has decidedly proven to be useful. But first, I’d like to throw out a question: “Does your open source community have an official local development environment to optimally support development and innovation?” There is a PHP-based open source CMS community that has more than 39 different local development environments based on many different technologies: Bash scripts, VM, Docker containers, etc. Accordingly, the quality of the solutions produced varies considerably. There are two obstacles standing in the way of another CMS community: an obsolete virtual machine and a lot of controversy over how containers should be properly configured. Developers are pretty much on their own here. In both cases, resources are wasted on these issues. Time and energy are lost which could otherwise, in good open-source style, flow purposefully in an atmosphere of cooperation and the development of common solutions.
DDEV-Local is a technology that can provide practical results with little effort. The tool is free and open source, with an active and rapidly growing community. It is being advanced by a professional development team and is also subject to full test coverage during development. With DDEV, a state-of-the-art container-based TYPO3 CMS installation can be started in just a few minutes.
“One for all, all for one?” Many technologies, how many tools?
Let’s assume that WordPress developers at an agency are confronted with PHP issues that they cannot solve at the drop of a hat. Can a senior PHP, Drupal or TYPO3 CMS developer jump in quickly here to support the team? Are the same tools, environments and standards used everywhere? Or do you have to master different working methods for each (PHP) technology?
With DDEV-Local, development teams can use one and the same tool for all PHP CMS. Once you learn the set of commands, you can handle any project. Within minutes, you can have an exact copy of a project at your fingertips, including its complete environment. Then you can get to work: make changes, check in code, discard the environment, and so on. Better and faster feedback loops can reduce the time needed to isolate, fix, and deploy fixes for critical issues.
How long does it take to onboard new colleagues?
How much time is needed until new developers on the team can deliver production code? A day? A week? It may take a long time to become familiar with different tool sets used to develop and deploy multiple technologies. I’ve seen agencies where onboarding took weeks or even months. This leads to frustration in new colleagues as well as unnecessary cost for the company. In places where everyone can choose their own environment and tools, you often experience the notorious “It works on my machine!” issue between colleagues (as well as between local and production environments). This leads to the time-consuming and nerve-wracking search for the cause of incompatibility.
DDEV-Local can reduce the time to the first production commit from days or weeks to a few hours in real agency conditions. The reduced complexity thereby promotes consistency and improves the (self-)confidence of the developers. I’ve been told that the quick and easy deployment of sites in a matter of seconds or minutes can significantly increase the code deployment frequency for real production projects.
How much does complexity cost?
Companies or the community lose a lot of time, money and nerves due to complexity and configuration issues in local development environments. Every project has to be reconfigured and switching between the individual CMS, PHP versions or the web server is time consuming. Also, you often see problems during deployment. Increased complexity can lead to reduced and unpredictable release and maintenance speeds, leaving less room for targeted innovation. You lose time with low-quality problems that distract you from high-quality solutions.
DDEV-Local is not just a universal tool for PHP development. If the agency also hosts container-based hosting, you can do development in virtually all work phases (Dev-Test-Deploy) in the final hosting environment, which can lead to significant time-savings and increased quality. DDEV domesticates the containers and assumes the complexity: Docker configuration, development environments and dependency management are fully supported. DDEV should help make the dev-to-deploy workflow become faster, more efficient, and more reliable by providing the ability to work everywhere with identical environments: from the local machine through testing/QA to live production, especially if you are hosting with Docker containers.
A practical guide to the integration of a DDEV-Local into the web development workflow can be found in this box: “DDEV-Local: brief instructions and notes for use”.
DDEV-Local: Brief instructions and notes for use
Brief instructions for the integration of DDEV-Local
Step 1: Prepare. Make sure your computer is compatible with DDEV-Local. DDEV is compatible with macOS, Linux and a growing number of Windows systems [1]. Install and/or update the system requirements [1], mainly the Docker version 17.05 or higher (additionally on Linux you absolutely need to follow these steps after installation [2]) and docker-compose 1.10.0 or higher (Docker bundled with Docker for Mac and Docker for Windows).
Step 2: Install. Follow the instructions for installing DDEV-Local for your operating system [3]. DRUD Tech recommends for example that MacOS users download, install and upgrade via Homebrew [4]: brew tap drud/ddev && brew install ddev.
Tip: If you are already running a web server on port 80, an error message will appear. In this case, follow the steps from [5] to resolve the port conflict.
Step 3: Set up the project. The site code should be checked out to a local directory. This is the project directory. On the command line, navigate to the project directory and enter ddev config to set up the project. For each new project, DDEV-Local asks three questions that you should answer by providing your information: What is the name of the site? Where is the Docroot located? What type of project is this? (TYPO3 CMS, Drupal, PHP, WordPress, etc.)
Follow the configuration examples in the Quick Start Guides in the documentation for the CMS you are working on (such as TYPO3 CMS, Drupal 8, WordPress). Depending on the CMS and whether the project is a brand new or existing site, DDEV-Local will try to create the CMS-specific setting files [6].
Tip: If you set the project type to “PHP”, you can work with a number of other systems, such as Flatfile CMS generators, symfony, and many more.
If you are about to import an existing site into your DDEV-Local environment, follow steps [7] to import the database. Then run ddev describe to retrieve the database credentials for the project. This configuration only needs to be done once for each project. You can view the DDEV-Local configuration of the project in the .ddev / ddev.yaml file.
Notes on using DDEV-Local
To view a list of current DDEV projects on your machine, enter dev list. The command line displays which projects are configured, their status, and a link to access each project.
Start the project: Every time you want to work on a project, run ddev start from the project directory. You can also start any project from any folder by entering ddev start project name (replace “projectname” with the actual name of your project).
Tip: The same applies to other DDEV CLI commands. Execute them directly from the project docroot or from any folder by specifying the project name.
Remove the container: When you are finished with your tasks, remove the project by entering ddev remove. This preserves the database and maintains the status of the project without wasting system resources.
Tip: Since ddev remove does not delete the database, starting it the next time will be significantly easier. The next time you want to work on this project, enter ddev start project name, or navigate to the project directory and enter ddev start. If you additionally need to delete the database, add the —remove-data flag and the database is removed: ddev remove –remove-data
If you want to update DDEV-Local, please follow the instructions in the installation guide [3]. MacOS users using homebrew should enter the following: brew upgrade ddev.
For a complete list of available DDEV commands, see the DDEV-Local manual pages: ddev or ddev -h.
Setup stacks even faster with ready-made recipes
DDEV-Local supports a number of popular CMS and not only through “recipes” (Quick Start Guides [8] for Drupal-6, -7, -8, TYPO3 CMS, WordPress and Backdrop CMS) which show how corresponding CMS projects can be quickly set up in DDEV-Local. In addition, DDEV-Local comes supplied with several useful developer tools [9], including a web server, a database server, debugging tools, command-line tools and a dependency manager. You can access these tools for single commands by entering ddev exec
- MySQL Client (mysql) – command line interface for interaction with MySQL
- Composer – Dependency Manager for PHP
- Drush – command-line shell and Unix script interface for Drupal
- WP-CLI – command line tools for managing WordPress installations
- MailHog – Mail Catcher for intercepting and checking emails
DDEV can also facilitate work with other tools, for example Sequel Pro, a Mac database management application for working with MySQL and MariaDB databases. To this end, start directly from the command line by entering ddev sequelpro and connect these databases to the database of the project.
Moreover, you can guarantee continuity between projects and employees with project-specific configurations by specifying PHP versions and dependencies and adding the services to the projects. If you are familiar with Docker and Docker Compose, you can also define other services for your projects [10]. To for example add Apache Solr to a project, you can follow the tutorial at [11].
Conclusion: Open source, flexible, very user-friendly
DDEV-Local is open source, licensed with the Apache 2.0 license and has a wide community standing behind it that is involved in the development of the CMS. DDEV is currently supplied with pre-configured environments for Drupal 6/7/8, TYPO3 CMS, Backdrop CMS, WordPress, and PHP applications. DDEV-Local can be integrated with a variety of services, hosting providers and deployment scenarios – including cloud, in-house or hybrid hosting models. The modular, expandable architecture of DDEV is robust and thoroughly tested. DDEV can simplify the integration of containers into dev-to-deploy workflows and also provides environments that can be set up in minutes.
Links & literature
[1] System Requirements: https://ddev.readthedocs.io/en/latest/#system-requirements[2] Linux – steps after installation: https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user
[3] Installation instructions for DDEW Local: https://ddev.readthedocs.io/en/latest/#installation
[4] https://brew.sh/
[5] Steps in case of an error message: https://ddev.readthedocs.io/en/latest/users/troubleshooting/
[6] CMS-specific setting files: https://ddev.readthedocs.io/en/latest/users/cli-usage/#getting-started
[7] Steps to Import the database: https://ddev.readthedocs.io/en/latest/users/cli-usage/#importing-assets-for-an-existing-project
[8] Quick Start Guides: https://ddev.readthedocs.io/en/latest/users/cli-usage/#quickstart-guides
[9] Using Developer Tools with ddev: https://ddev.readthedocs.io/en/latest/users/developer-tools/
[10] Defining an additional service with Docker Compose: https://ddev.readthedocs.io/en/latest/users/extend/custom-compose-files/
[11] Guide to adding Apache Solr to the project: https://ddev.readthedocs.io/en/latest/users/extend/additional-services/#apache-solr
