There’s a reason why many engineering teams have added Docker to their tech stacks. Whether it’s the ability to easily build applications or the promise of secure, fast deployment, the benefits of using the open-source platform in day-to-day work are seemingly endless.
Kirk Gordon is one of countless developers with a love for Docker. As the tech lead for internal tools at dog food brand The Farmer’s Dog, Gordon said he and his team use the platform throughout their workflow, particularly benefiting from its portability, which has reduced the amount of “well, it works on my machine” conversations.
While Gordon and his teammates have witnessed several benefits from the platform so far, the improvement in replicating build and test failures stands out to him the most.
“We use Docker Compose in our continuous integration pipelines,” Gordon said. “For large-scope tests that fail, this makes it very easy for anyone to launch the same environment locally to rerun the tests with a few compose commands to investigate the failure.”
Built In NYC checked in with Gordon to learn how his team has leveraged Docker to improve their workflow.
Tell us a bit about how Docker fits into your tech stack and how you leverage it in your work.
We use it throughout our workflow. Typically, if an application is containerized, you will find a Docker Compose file along with the Dockerfile in its repository. This allows our developers to run a stack locally that is similar to our various remote environments. We also prefer to use Docker Compose in our continuous integration pipelines so we can easily reproduce the steps to build and test locally without having to depend on a proprietary feature of whichever continuous integration runner we are using.
Lastly, the build aspect itself is very important to us. There are several benefits from having the immutable artifact that is the output of a Docker build. For example, it helps eliminate the risk of configuration drift that can occur with one-off changes made in production. It also allows us to quickly inspect failures. If an application fails to start in any context, it’s often fastest to run the image for that specific build locally to find out what the issue might be.
What is your number one favorite thing about Docker?
The portability it provides: There are a lot fewer “it works on my machine” conversations. We run our apps in a number of different contexts: on laptops running various versions of macOS or Linux, on servers running different Linux distros, and even on generic remote Docker engines with unknown underlying operating systems and configurations. If we had to bootstrap our application from source or pack virtual machines of some sort, this would be much more difficult or even impossible.
Even with higher-level languages, there are sometimes interactions with various aspects of the runtime environment. While not frequent, it introduces ambiguity when something goes wrong and must be investigated. It’s nice to be able to pull the same image and launch a container while retaining a relative amount of confidence that the local environment is not a contributing factor if it doesn’t work as expected.
A big improvement we have seen is in replicating build and test failures.”
What's the biggest improvement your team has seen since adding Docker to your tech stack?
We have been using Docker for several years. A big improvement we have seen is in replicating build and test failures. As mentioned, we use Docker Compose in our continuous integration pipelines. For large-scope tests that fail, this makes it very easy for anyone to launch the same environment locally to rerun the tests with a few compose commands to investigate the failure. Before this, we had the environment described in the continuous integration runner’s configuration directly, and it took quite a bit of expertise to understand how all the options might or might not affect the software under test. This provided some challenges when attempting to rerun locally, and there was always some doubt something might be out of sync if we got a different result on the local rerun.
