The 12-factor app manifesto (sometimes called as 12-factor app configuration style) is more like a guidance on ideal practices (or principles, if you want) for building softwares delivered as a services. It can be applied to applications written in any programming language.
The 12-factor-app “word” is often used interchangeably with cloud native practices. These practices cover implementing, deploying, monitoring and managing applications, and they can be implemented in any programming language.
I. CODEBASE
One codebase tracked in revision control, many deploys
This statement says that you should have only one repository for your codebase that is accessible to the developers within your organization. You can still use various branches, while having different repositories is not allowed in a 12-factor environment. This one codebase is stored in a revision control system and supports many deployments.
Nowadays, this is mostly handled with the use of GIT.
Best practice is to automate deployment, and some of the popular technologies to achieve this are Gradle and Jenkins.
There is only one codebase per application (but there will be many deployments of the app – a deploy is a running instance of the application). Multiple apps sharing the same code is a violation of twelve-factor!!!
II. DEPENDENCIES
Explicitly declare and isolate dependencies
The second principles of 12-factor app refers to application dependencies. Any dependency you application rely on to run must be managed in such way to avoid conflicts.
A twelve factor app declares all it’s dependencies, completely and exactly, by means of a dependency declaration manifest. For example in maven you have pom.xml while in gradle you have gradle.build files.
III. CONFIG
Store config in the environment
An application’s configuration is everything that vary between deploys.
I consider this to be the most important rule. Configuration variables should always be separated from the source code, and never be hardcoded. Instead they should be handled with the use of environment variables, or externalized in properties files. Examples of app configuration variables are:
- configuration location of a database in preProduction vs. production;
- credentials to external services.
Following this practice enables the same code to be deployed to different environments, without changes.
IV. BACKING SERVICES
Treat backing services as attached resources
A backing service is any service that the application consumes over network as part of its normal operation. The backing services may run on the same machine, or different machines in third-party servers. The following are backing service examples that should be treat as attached resources:
- databases
- messaging systems
- SMTP services
- LDAP servers
V. BUID, RELEASE, RUN
Strictly separate build and run stages
Twelve factor processes must be stateless and share nothing.
VI. PROCESSES
Execute the app as one or more stateless processes
This principles says that twelve factor app are stateless and share nothing.
VII. PORT BINDING
Export services via port binding
An application architected according to twelve-factor-app as a service by binding to a port, and listening to requests coming on that port.
VIII. CONCURENCY
Scale out via the process model
IX. DISPOSABILITY
Maximize robustness with fast startup and graceful shutdown
This ninths factor says that a twelve-factor-app’s process can be started or stopped at a moment’s notice.
X. Dev/Prod PARITY
Keep development, staging, and production as similar as possible
You don’t want development and production to get out of sync so that one does not reflect the other, you want them to be reasonably similar! This falls into agile software development, continuous integration and continuous deployment concepts.
XI. LOGs
Treat logs as event streams
A twelve factor app never concern itself with routing or storage of its output stream. (logs are examples of application output streams collected from the running processes and backing services).
XII. ADMIN PROCESSES
Run admin/management tasks as one-off processes