Why did we build local development and web hosting solutions?
The complexity of early enterprise Drupal projects such as www.popsci.com demonstrated the difficulty of moving between stages in the development process and replicating the stresses of the production site during development. Every team member had to configure their local AMP stack for every project they touched, with no easy way to ensure parity from one machine to the next. Delivering a code base and assets to the client’s internal operations team for deployment meant physically flying to headquarters and sitting down with the team to communicate the requirements of the application and associated services.
That meant that any time a project moved, whether between team members for collaboration or to staging and production servers, environmental differences between development and delivery often surfaced, leading to hours of debugging and validation. As we struggled with handoffs to other team members and to the client’s operations team, we began to realize something was seriously broken with the process and the tools. How could a 15 minute code update take over 3 hours to get everything synced and updated live?
The problem was complexity. Each project needed environment configuration, importing assets, setting up customized services, databases, configuring web servers, memory allocation… etc. Once the site was delivered it would be under load experiencing pressure that was not easy to replicate in development. As complexity increased, we needed more hardware and extremely talented engineers who could navigate complexity and who weren’t easy to find. This led to exploring a solution that could manage the complexity in a way junior engineers could adapt to quickly.
Solving complexity in web development
To start solving this problem of complexity and collaboration, we began by simply documenting the process. By writing down the steps required to get a project set up on a local machine or moved to a production server, we were able to standardize and at least smooth out some of the speedbumps. Still, creating these complex sites for clients with lofty goals and very specific plans was causing us some big problems. A manual checklist wasn’t going to be enough for us to do this at scale, for multiple projects or multiple clients.
This realization led us to the major focal points for what would become the DDEV solution. First, even using scripted installation profiles and migrations, subtle differences would surface in environment configurations. We needed a more unified, reliable way to replicate production environments on local machines.
We also had to have a way to merge and deploy changes automatically, in a way that could be viewed, tested and approved as a whole project, rather than individual PRs. It became difficult to find a place to host the projects clients had us building. None of the hosting providers at the time provided managed services that were designed to help the site succeed, hence the need on our team for engineers skilled in multiple disciplines to do the server management.
The concept of improving local development began to take hold initially not by planning to build a tool, but by scripting our checklists into installation and migration profiles. These scripts were then converted to Jenkins jobs to ensure management of external environments. While that was a huge improvement, it was very fragile and prone to unexpected errors in different environments.
The concept of finding a way to pull all of the changes together as a whole and run them in an environment that was fast enough and could meet our needs led us down the road to “self-hosting.” At the time, as an agency building these sites, we realized that while we could build a self-hosted production environment, that really was not our core business.
Building on the lessons we learned from managing agencies, building enterprise sites, combined with deep open source knowledge, we decided to spin out DDEV as a separate company. Our focus would be on advancing developers in open source communities by sharing the tools and processes we built to solve our own problems.
It was at this intersection that we realized there was a significant gap for web developers, specifically PHP developers, that we were right in the middle of trying to solve. Like most startups, we looked in the mirror and said, “We can build a product to do this… it can’t be that difficult!”
It turns out that solving a complex problem is complex. Our overarching design goals from the very beginning for DDEV were focused on:
- Reducing and managing complexity in the development process
- Creating an easy way for team members to get a local copy of a project to work on
- Creating a repeatable way for teams to work together using this process
- Making best practices the easiest choice for developers
If doing something the right way isn’t also the easiest and fastest way, then developers won’t be happy about it and their productivity will be adversely affected. To unify and simplify the experience, we’ve focused on providing a complete end to end solution for the development and deployment of complex web projects. Docker and Kubernetes have also enabled us to build the platform we envisioned thanks to mature container technology and communities.
We’ve taken into account the many steps in the process of designing, building, deploying and maintaining web apps and digital properties. Each project has unique requirements. Each client has different technologies in play. Each developer has unique skill sets. We are focused on creating a solution that allows each developer, client, and project a way to work together no matter what part of the project they are working on.
DDEV local development and hosting today
In 2017 we released our first supported version of our local development tool, DDEV-Local. The tool is fully open sourced under the Apache license and has benefited from over 100 contributors adding to the code, documentation, as well as giving presentations on usage around the world. DDEV-Local has attracted thousands of developers to adopt it as their standard because of the quick startup time, ability to run multiple projects at once, share with colleagues and collaborators, and customize configurations.
There are DDEV-Local quickstart guides available for Drupal, TYPO3, WordPress, Backdrop, Magento and Laravel, but just about any PHP project will easily run in DDEV. Some other top web applications that use DDEV include Sulu, CraftCMS, Symfony, Flexitype, Bludit, and plenty more, thanks again to the contributors who share their recipes and blogs.
Some common daily use cases include sales demos, client sign off, team input, testing new modules or code and reviewing patches in the issue queue. DDEV has become part and parcel of daily work for thousands of PHP developers. As teams and individuals see success with DDEV, scaling that success by encouraging workflow changes, creating clean development environments and increasing collaboration is something that DDEV is committed to and drives the continued innovation of this product.
In 2018 we released the first version of DDEV-Live, our Kubernetes-based hosting platform. Earlier this year, in March of 2020, we released the second major version of DDEV-Live, focusing on more cloud native principles, GitOps concepts, and designed around an API-first architecture to allow developers an easy way to communicate directly with the platform.
Later this year we will be releasing some new functionality that will act as a bridge between the DDEV-Local development tool and the DDEV-Live hosting platform. We will continue to focus on enabling teams to have the best workflow dynamics possible through developing the DDEV API to offer flexibility and customization for all team project needs.