The Twelve-Factor App: How To Embrace The Future
Tags: devops, webdev, career, productivity
Published: 2019-11-30 09:17:35

---
title: The Twelve-Factor App: How To Embrace The Future
published: true
description: Why you should embrace The Twelve-Factor App methodology
tags: devops, webdev, career, productivity
cover_image: https://thepracticaldev.s3.amazonaws.com/i/uz3zc2lltm13i4dfw4wh.jpg
---

In this article, I will explain to you the Twelve-Factor App development guidelines, why it's not a passing fad, and how you can use it to literally (well, figuratively) embrace the future.

# What Is The Twelve-Factor App?

The Twelve-Factor app is a set of best practices for building modern web applications. There are twelve guidelines (hence the name) that are recommended to be followed by every developer to build scalable applications.

A Twelve-Factor App is described as:

1. Automated from a development perspective;
2. Portable across execution environments;
3. Deployable in the cloud minimizing the need for servers and server administration;
4. Enabled for continuous deployment with minimal divergence between development and production environments; and
5. Scalable without significant change or effort.

# What Are The Twelve Factors?

I'll briefly cover each of the factors. However, for an in-depth explanation be sure to check out the official site of The Twelve-Factor App: [https://12factor.net/](https://12factor.net/)

## 1. Codebase

Essentially, there will always be only one code repository for a given app. This can be any version control system such as **Git**, **Mercurial** or **Subversion**. There will be many deployments of an app, however, the app can be run in different environments (local/production).

## 2. Dependencies

**NEVER** directly copy a dependency into your codebase. You want to use a package manager to explicitly declare and isolate your dependencies. For JavaScript, popular package managers include *npm* or *yarn*.  

## 3. Config

The config should always be stored in an Environment Variable. You want the config file to be separated away from the code as the config varies throughout deployment and the code does not.

## 4. Backing services

Treat your backing services as attached resources. This means that you want to make your services easily interchangeable so that you can swap to a different third-party service provider without any changes to the app’s code.

## 5. Build, release, run

The twelve-factor app uses strict separation between the build, release, and run stages. The build process is run when new code is deployed. Every release should always have a unique release ID, such as a timestamp of the release or an incrementing number. Then you are able to run the release in an execution environment.

## 6. Processes

**DO NOT** introduce state in the processes. Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.

## 7. Port binding

The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. Make sure that you export your services via port binding. The service should be visible to other services as they may be used. 

## 8. Concurrency

By separating your app into smaller pieces you are able to scale the services. This reduces the workload as an individual VM can only grow so large (vertical scale), so it is important for the app to span across multiple processes on  multiple physical machines.

## 9. Disposability

Processes are disposable, so make sure that they can be started or stopped fast. By doing so this facilitates automatic scaling, rapid and ease of deployment.

## 10. Dev/prod parity

Keep development, staging, and production as similar as possible so that anyone working on a project is able to pick it up and release it. Continuous deployment between development and production is imperative to limit failures and errors.

## 11. Logs

Treat logs as event streams. Logs are useful for checking up on your apps processes and backing services. You should never concern the routing or storage of its output stream with your app. Instead, think of these logs as having no fixed beginning or end but flows on a continuous stream as long as the app is running.

## 12. Admin processes

Run admin/management tasks as one-off processes for tasks like database migrations and executing one-time scripts in the environment.

# What Now?

Regardless of your framework and tech stack, you can implement Twelve-Factor App principles into your application! Some great resources that naturally complement the Twelve-Factor App's principles include:

- [Dotenv](https://www.npmjs.com/package/dotenv) for configuring environments (the link is for Node.js but different versions are available for different languages and frameworks)
- [Docker](http://docker.com/) for setting up containers and creating perfect development/deployment environments effortlessly;
- [Kubernetes](https://kubernetes.io/) for managing and scaling containers for production-grade uses;
- [AWS](https://aws.amazon.com/) for hosting a deployed Twelve-Factor App; and
- So many more!

This above list is by no means exhaustive. I'll end this article encouraging you to do your own research and find more tools that you can incorporate into your stack. Like it or not, these Twelve-Factor App principles are becoming more and more common, so the best time to get started is now!