How DDEV Can Help Solve Local Web Development Challenges

If you’ve worked on a team of web developers you know how hard it can be to work with your collaborators when building or updating a site. In the old days, teams used to try working on the same site and the same code in real time, sometimes even on the live or staging server. That just didn’t work. Today, this doesn’t happen anymore; however, we still face different web development challenges.

Git Source Control Isn’t Enough, We Need Separate Workspaces

Almost everybody these days has their site’s code in git source control. Git, which has an open source foundation, is a distributed version control system that allows software development teams to have multiple local copies of the project’s codebase. Developers can create, change, merge, and delete copies simultaneously but independently of each other, thereby enabling collaborative experimentation.

Git source control clearly shows all the changes in a given repository. However, as in any other collaborative project, it’s important that everybody is not making changes to everything at the same time. When working separately on a particular feature or bugfix, it’s customary to create a formal “Pull Request” or “Merge Request” in order to upload and document changes — this is then reviewed by a team lead or other “Gatekeeper” who can comment on it, accept it, or reject it, but it doesn’t become part of the codebase until the gatekeeper “pulls” it, or “merges” it.

A Gatekeeper for Merge Requests also Doesn’t Prevent All Issues

A gatekeeper helps to support the git control merge requests, but there’s another problem. The local development environment on one developer’s machine doesn’t work the same as another developer’s… or that it doesn’t work at all. If every developer “rolls their own” environment, what works on one computer may not work on a colleague’s workstation. Different developers may be working with different operating systems and different versions of those operating systems, so it can get complicated pretty fast. Some team leads have been known to spend most of their time repairing junior developers’ local environments.

Working Separately in a Local Development Environment Creates an Exact Replica of an Environment

Many developers use DDEV, an open source, free local web development tool, to address this problem. If a project’s code includes the DDEV configuration, then each team member will have the exact same environment, with the exact same results. And that’s true even if one developer is working on Windows WSL2, another on Linux, and others on Apple Silicon Macs or Intel-based Macs. It just works the same. And the webserving is fast.

👁 Image

As an open source tool, DDEV comes with many benefits in terms of its compatibility and adaptability for quickly launching local PHP, Node.js, and HTML/JS development environments. While it isn’t perfect or always a fit for every project, the open source nature and flexibility for most applications of its use makes a strong case for using it to support team collaboration.

There are a few tips for using DDEV that may help ease the transition for a team’s collaborative development experience:

1. Your team lead should manage the DDEV configuration, and change it, when it needs to be changed, with a merge request. Team members can then update to the latest code, `ddev poweroff` and `ddev start`, and right away they have the same configuration. Your DDEV configuration should have a PHP version and database type/version that match your production environment (DDEV supports MySQL, MariaDB, and Postgres in many versions).
2. Developers can save and restore database state with `ddev snapshot`, preferably giving a name to the snapshot. For example, `ddev snapshot –name=upgraded-laravel4.0`. Then you can restore it with `ddev snapshot restore`. This allows you to experiment with changes that are stored in the database, or checkpoint changes done in migrations, for example.
3. DDEV Add-ons allow easy addition of specialized components for your project. Use `ddev get –list` to see officially maintained add-ons like redis, solr, elasticsearch, varnish, and many more, or `ddev get –list –all` to see all the add-ons the community has created. Use `ddev get <add-on>` to add one to your project.
4. `ddev share` lets you share your running project with a stakeholder anywhere in the world. It requires a free Ngrok account, but is easy to use.
5. If your team requires quick access to a procedure not already built into DDEV, it’s trivial to create a custom command. These are just simple shell scripts, and can add custom features to all your projects if installed globally, or to specific projects.

To dip your toes into the DDEV waters,

●  Try installing and creating a simple project. It takes just a few minutes, and it will not mess up your computer.

●  Try creating a “quickstart” project with your favorite CMS or platform, see the Quickstart section of the docs.

●  Try some common tasks.

●  Read the FAQ.

●  Stop in at one of the DDEV support venues.

The bottom line about development and web development is that every developer needs a separate workspace, where they can work on the code and the database without affecting any other developer’s situation. This approach is widely accepted and essential to modern development.

A local development tool helps create easy local environments by replicating the upstream website with code, database, and user-generated files. DDEV is a good example because it’s Docker-based, works in many environments, and requires nearly nothing to get your project working in multiple environments. You don’t have to know anything about Docker — just a few commands will get you started. Developers can then work on any facet of the website code, polish their results, and create a merge request to the project code.