DevOps Tooling for Local Development

DevOps Tooling for Local Development

Simple Thread is a design and engineering agency that focuses on building digital products. So we are often required to create cloud environments to run those digital products. We have a standard stack that we lean on for that work – including AWS, ECS, Terraform, and Docker – in order to keep environments consistent and reproducible.

For as much attention as these cloud environments get, sometimes local development environments can be a bit neglected – especially when you’ve had a consistent team working on a product for a long time. They’ve built up a lot of knowledge, and the environment can drift, resulting in a rigid and hard-to-manage environment that requires a lot of project familiarity in order to get things up and running.

Relieving this sort of pain is usually just a matter of priorities, since all of the tooling is well established to provide repeatable and reproducible environments even on a developer’s local machine. As a former system administrator, when I started my software development career, I was surprised to see how often we still have these issues when coming onto an existing project or starting a new project with other developers.

There are small things that we can do to speed up the process, document changes, and make the environments much more flexible and reliable. This can all be accomplished utilizing existing software and tools that are in the typical system administrator’s toolbelt.

Leveraging Sysadmin Tools

We are going to look at what system administration tools you can use to make different aspects of your local environments reproducible and reusable.


Software development environments usually don’t respond well to even small changes in the operating system, hardware, network setup, etc. So what can software engineers do? The most important step in solving any complex problem is to account for as many variables as possible and extract them out. Luckily there are tools that currently exist and can be utilized to reach this goal. Docker is one of the more popular tools for encapsulating the entire environment. There can be trade offs with trying to encapsulate the entire environment though, particularly around local resource usage, performance, and complexity.


If you don’t want to encapsulate your environment with a tool like Docker, then you might want to reach for something like Ansible by Redhat. Ansible is perfect for making environments significantly more reproducible. It achieves this by providing an engine that can configure, modify, and execute all that would be needed for anyone to set up an identical environment every time. Ansible uses YAML files to execute changes on a system level, meaning it can make direct changes without manual intervention. By making changes from within the YAML files to address changes to the development environment, once a change is made and confirmed it can then be stored in a repository for future reference or so that others can easily get a similar environment started. A drawback to this tool is that since it will be executing commands at the system level, you just need to be careful that you aren’t executing commands that depend heavily on everyone having the same operating system and in some cases even the same version. Utilizing this technique will ensure that any changes local environment will be captured and will extract some of the project specific knowledge that someone else might not have.


In software development, there is a common principle called DRY. It stands for Don’t Repeat Yourself, and it is a way of thinking that forces a developer to consider if something needs to be done twice in the same way that it should only be written / defined once and then reused. This is not a new concept to a majority of developers, but it is often overlooked when setting up environments. Every time there is a change or an adjustment that needs to be made, it is done manually. If the team is well tuned, that change will be documented and everyone will be aware of needing to make said changes or their environment will not function correctly. A perfect example of this is updating database seeds or environment variables. What if the DRY principle was applied to this situation? Luckily there are a few different tools that can help with that as well, tools that system administrators have been using for awhile. Packer by Hashicorp is perfect for implementing this. This tool handles the problem by abstracting the entire system into a packaged image that can be used to create exact replicas of itself with little effort. It does this by making images, so if you have a virtual machine and want to be able to quickly get a new node for your environment started or if you want to have someone onboard rapidly, then this tool would be perfect to handle that situation.


There are a lot of different system administration tools that can be used in software development that can make environments more efficient and reproducible. This barely scratches the surface of the topic, but as the lines between development and operations continue to blur with DevOps gaining more momentum, it is only a matter of time until practices like this become common for a software developer. A big thing that the developer needs to understand is that a lot of the work has already been done on the tooling, and they just need to implement the right ones to get a consistent and well designed environment for their applications.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All