Enabling fast flow of work from Dev to Deploy with DevOps best practices

Log Jam Priest River

On-demand environments are essential to delivering code—and therefore value—from dev-to-deploy rapidly, reliably, and regularly. At every stage of the workflow, the environment has to be as close to the production setup as possible to avoid nasty surprises when your code hits production. Defining your “production-like” environment with automated build mechanisms to create containers—like in DDEV-Local—lets anyone get to work on development or testing on their own machine in minutes with high confidence that their code will work well in production, too.

Imagine your workflow as a river full of logs floating downstream to the sawmill. Each log is a piece of work in progress (WIP). They float down the river, guided around obstacles and curves by experienced loggers, and arrive at the mill to be cut into boards—success! When everything is flowing smoothly and regularly, things are great. But if one log gets turned around or caught, everything backs up and overflows, creating a dangerous logjam with huge tree trunks flipping around, loggers severely injured, and work coming to a halt. The jam has to be carefully picked apart and gently guided into flowing again. Moral of the story: You can’t stop WIP without creating bigger and more extensive problems up- and downstream.

Waiting for a testing environment to be provisioned or a virtual machine to spin up on your local machine is an example of one source of these “logjams.” Rather than waiting on your operations team, or your slow virtual machine, to provide an environment for you to work or test in, why not have an environment you can spin up independently? On-demand production-like environments allow developers to get started immediately, test frequently, and deploy without disaster. DDEV spins up new or existing projects in a consistent environment in just a couple of minutes.

The DevOps Way

According to GitLab’s 2018 Developer Survey, “a majority (67%) of all respondents agreed that using a DevOps workflow saves time during the development process.” To that end, many businesses are adopting DevOps best practices that focus on the fast flow of work, fast flow of feedback, and continuous learning and experimentation. These “Three Ways of Work” as described in the DevOps Handbook, allow you and your team to move quickly, deploy frequently, and to view failure as a learning opportunity.

The First Way, which we’ll focus on here, sets out methods and goals to speed the flow of “high-quality, stable work from development to the customer with frequent delivery of small batches and reduced lead time.”

Features and fixes can be deployed frequently; feedback comes soon after development, and in turn, informs the next development and deployment cycle. In other words, continuous delivery of features and continuous integration of feedback. Key factors in the process include limiting work in progress, building systems that are safe to change, and creating production-like environments on demand. Having these matching environments available for local development, testing, and production deployment helps ensure that your code can be deployed quickly and reliably.

It’s all a product of your environment

Developers can only have confidence about moving code from their local development environment to the production server if both have the same stack of resources available. For example, you’ve invested several hours into your project and are ready to deploy. If you haven’t been working in production-like environments, you could be in for a large, unpleasant surprise in production. Your team will have another sort of logjam on your hands. When production goes down, everyone has to drop everything else, sort out what went wrong, undo it, and fix any resulting issues. That’s a big drain on everyone’s time and the customer’s bottom line could be affected.

On the other hand, enabling developers to work with the same environment for local development, testing, and on the live site will result in the code deploying smoothly on the production server with no unexpected “but it works on my machine” issues.

Putting control of on-demand local and testing environments directly into the hands of developers is more effective. Ideally, the environment-creation process will be automated and the necessary scripts and configuration will be included in the project’s version control repository. Local testing gives developers immediate feedback with which they can remedy any problems and learn from the experience, increasing their mastery of their craft over time. Even with testing, the longer the delay between development and deployment, the harder it will be to learn from the resulting feedback and the more likely it will be that something else will have changed and caused another logjam and other work will be blocked.

Keep in mind, speed in and of itself is not the goal here—simply moving faster would do us no good if the flow is full of errors, backlogs, or lacking useful feedback. The goal is to release small, stable pieces of work frequently and reliably, then iterate on that work, and continue to take measured steps forward to deliver value.

Speed and Automation with DDEV

If you’re working with multiple projects using a wide variety of systems and servers, it can be difficult to juggle all the configuration and files. You need a tool that can handle it all and deliver value to your customers more often and more reliably. Getting a production-like environment up-and-running on your machine—whether Windows, Mac, or Linux— only takes a couple of minutes, thanks to automated provisioning and version controlled configuration with DDEV-Local. DDEV was created with the developer in mind. It relieves you of the burden of slow tooling and tedious, error-prone manual setup and it speeds your workflow.

“The last thing I need is more complexity. I need to work on several client projects at once, so task-switching needs to be painless and fast.” – Danita Bowman, Owner & Developer at DSquaredB Consulting

DDEV is highly resilient because it’s architected with containers. In the cloud, containers are self-healing so if one fails another can spin up on demand. On your local machine, they don’t use up excessive system resources when running or idle. When things break, you can stop and remove the container stack and start over quickly and easily. Feel free to experiment and try something new—you’ll know right away if it will break in production because your DDEV-Local environment shares the same configuration.

An on-demand, production-like environment, version-controlled and clearly defined with configuration is stable, reliable, consistent and secure. DDEV-Local provides all of these features out of the box, is highly configurable and portable, and will enable you and your team to deploy earlier and more often. If you’re interested in embedding the principles of DevOps in your work and maximizing the flow of product to your clients by enabling the creation of on-demand environments, try DDEV right now and view a project in minutes in your browser—that’s on-demand!

Test drive DDEV

Photo: public domain image of a log jam on Priest River

Share this post: