The Twelve-Factor App methodology is used to build scalable Software as a Service applications for enterprises. It can be applied to apps written in any language irrespective of what database, memory cache, or queue is used in the backend. The Twelve-Factor App method builds scalable, independent, portable, and resilient applications.
The 12 factors
-
Codebase
There should be only one codebase for every application and that codebase can be used for multiple deployments. There can be multiple branches but there should only be one repository. The code also should not be shared between applications; instead, build a code library, mark dependencies, and manage them using a package repository.
-
Dependencies
All dependencies should be declared explicitly and must not rely on system tools or libraries. The source should only store the unique code and no other external dependencies like Node.js packages or JAR files. These external dependencies should be stored in external, app-specific libraries and loaded during development, testing, and production. Dependencies should be isolated from the code and hosted in a repository within the app.
-
Config
Configurations that vary with deployments should be stored in the environment. An application should be independent of its configuration, and you must avoid storing configs in code. This means configurations should have a separate file instead of being hosted inside the source code repository. Twelve-factor apps also store configs as variables so they don't get checked into the repository, which is helpful when you have to edit the configuration file without affecting the actual codebase.
-
Backing services
Backing services are external components like databases, message brokers, external queues, email servers, and independent services and are treated as attached resources by twelve-factor apps. These attached resources can be swapped from one provider to another without affecting the codebase. This makes the software development life cycle more flexible and efficient.
-
Build, release, run
The delivery pipeline should have distinct build, release, and run stages.
Build stage: Converts the code repo into an executable bundle called build.
Release stage: Takes the generated build and combines it with the current config from the deployment environment.
Run stage: Runs the app in the execution environment.
-
Processes
Apps are executed in the execution environment as one or more stateless processes. Any data that needs to persist must be stored in a stateless backing service—typically a database—to ensure that nothing is shared. If needed, you can use Memcached or Redis, which store session state data instead of in-memory.
-
Port binding
Twelve-factor apps are self-contained and standalone and should not be deployed into external web servers; instead, use port binding to export services. For example, web apps export HTTP as a service by binding to a port. They listen to requests coming in on that port and make themselves available to other services through this port.
-
Concurrency
The Twelve-factor App method advocates horizontally scaling individual processes; instead of running them as one large system, it suggests running your apps as multiple processes. You should also separate those processes so different parts of an application can be scaled up or down.
-
Disposability
Applications should start and stop gracefully, without affecting the system. All databases and network resources should also terminate properly, and any new addition or deletion of an instance should not affect the application state. This ensures elastic scaling and rapid deployment of code and config changes.
-
Dev/prod parity
Ensure that your development, staging, and production environments are as similar as possible. Twelve-factor apps are designed for continuous deployment, so maintaining a minimal time gap, personnel gap, and tool gap can reduce bugs between different environments.
-
Logs
Each running process in an application should write an event stream and send it to a chosen location, not simply store log files. The execution environment captures, aggregates, stores, and indexes these log streams, which helps manage the logs from a single dashboard.
-
Admin processes
The Twelve-Factor App method suggests running tasks as one-off processes and keeping administrative tasks as a part of the codebase in the repository. One-off admin processes should be run using the same codebase and config as any process run against that release.
In summary
The Twelve-Factor App methodology is a principle that helps developers build and release scalable applications. With various automation and resilient processes in place, it organizes and channelizes the way applications are built and deployed.