The Twelve-Factor App Methodology
The twelve-factor app is a methodology used to develop SaaS apps or web apps with the help of Microservices. It serves as a practice guide to building apps when pressed for time or cost to hire new developers for a project and make them scale up without significant changes to tools or architecture. It allows organizing projects effectively and managing scalable applications.
This methodology was first introduced by the developers at Heroku in 2012 who created hundreds of applications and developed this methodology based on their experience. The methodology incorporates 12 principles each applying to a subset of an app and guiding developers in finding the best way to manage apps as a whole.
The principles it suggests are not constrained to any particular programming language or database.
Principle 1. Codebase
There should be one codebase with different environments.
The guideline expressed in this first factor suggests the principle of not creating another codebase, just for the sake of setup in different environments. For instance, there shouldn’t be two repositories (production and development) for one codebase. A distributed version control system can maintain and monitor the project source code. For developers, this makes accessibility easier.
Different environments represent different states. They all share the same codebase, whatever the state might be.
Principle 2. Dependencies
All dependencies should be declared, with no implicit reliance on system tools or libraries.
Including the dependencies into the codebase is a bad practice since it could create problems such as the underlying dependency of the platform. For instance, if the uploaded modules were from a Windows PC perspective, and the codebase was downloaded by a Mac OS developer, they would undoubtedly have problems running the project.
It’s better to use a package manager-depending on the technology stack – to download the dependencies on your respective system by reading a dependency declaration manifest containing the names and versions of the dependencies.
Principle 3. Config
Configurations are an important part of any application, especially when there is a need to support multiple environments or clients.
A configuration that varies between deployments should be stored in the environment. No one wants confidential information to be publicly available, such as database connection information or other sensitive data. The configuration is also largely dependent on the environment where it’s located.
There should be a strict separation between config and code. Code should remain the same irrespective of where the application is being deployed, but configurations can vary.
Principle 4. Backing Services
All backing services are treated as attached resources and attached and detached by the execution environment. Databases, external storage, message queues, etc. are external services and they can be considered as a resource. They may be accessed via some web-addresses/URLs or similar requests, then specified in the configuration. That way, the source of the service can be modified without affecting the core code of the app.
Principle 5. Build, Release, Run
A twelve-factor application requires a strict separation between Build, Release, and Run stages.
- First, the build phase. It is the assembly/compilation of the source code into an executable bundle while loading dependencies and creating assets. The build phase starts every time a new code needs to be deployed.
- Second, the stage of release. At this stage, the code produced during the build stage is combined with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.
- Third, the run stage. This is the final stage, which runs the application in the execution environment. It should not be intervened by any other stage.
Software deployment through this lifecycle is quick, continuous, and without any manual intervention.
Principle 6. Processes
Applications should be deployed as one or more stateless processes with persisted data stored on a backing service, typically a database.
The key principle of this factor is that the process is stateless and shares absolutely nothing. While many web systems rely on “sticky sessions”, storing data in the session expecting that the next request will come from the same service contradicts this approach.
Principle 7. Port Binding
A twelve-factor app should be independent of additional applications. Every function should be its own process.
This factor refers to an application binding itself to a particular port and responding to all the requests from that port. The port is declared as an environment variable and provided during execution.
Applications built on the basis of principle do not depend on a web server. The application is self-contained and runs standalone. The web server is packaged as a library and bundled wit