How to create consistent development environments that just work

I have worked as a member of numerous teams, as a team leader, and project manager.

In my 10 years as a developer, the one thing that has brought me to the brink of insanity more than any other is dealing with development environments.

What version of which language are we going to use? Which version manager? Which version of the version manager? How are we managing dependencies? Where are they going? What database are we using? How are we running the server? The tests? Why isn’t this working?

“I don’t know, it works for me…”

Docker

Docker is an excellent way to create consistent environments. If you aren’t already familiar with it, Docker’s own website provides a perfect explanation of what it does:

Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries — anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment.

Containers include the application and all of its dependencies — but share the kernel with other containers, running as isolated processes in user space on the host operating system. Docker containers are not tied to any specific infrastructure: they run on any computer, on any infrastructure, and in any cloud.

This containerization makes it so easy to create application environments that don’t step on each others toes. Each environment has exactly what it needs to run that application in isolation.

The only potential downside with Docker, is that to feel comfortable using it, you need to not only learn how Docker works, but you need to have some level of familiarity with Linux and DevOps concepts like containers, networking, etc.

This isn’t a bad thing, but it’s not something everyone is going to be able to accomplish. With how much Docker has to offer, the idea of making it more accessible to developers of all skill levels is becoming quite popular.

Nanobox is new to the growing list of tools attempting to bring Docker to everyone. It’s designed with the app developer in mind, providing a simple way to leverage Docker to create consistent, reusable, environments, allowing app developers to focus on building applications rather than infrastructure.

Set up a simple dev environment

Place a simple config file, called a boxfile.yml, at the root of any project:

# boxfile.ymlrun.config:engine: nodejs # php, python, ruby, golang, elixir, etc.

Now run nanobox run; This will use Docker to create an instant, isolated, dev environment for your project, and drop you into a console where your project code is mounted.

Set up a production environment

The reality is that no environment is going to be that simple. If you’re planning on running anything significant, you’re going to need a lot more.

The following example will provision an entire production level ruby on rails development environment (which can even be tested in a production setting with nanobox deploy dry-run).

Rinse and Repeat

No matter how many machines you run your application on, the result will always be the same: a consistent development environment that just works.