The Twelve Factors
Everything in revision control including environment configuration
git flow master - production develop - staging
Explicitly declare and isolate dependencies
Store config in the environment
In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.
4. Backing services
Treat backing services as attached resources.
Anything your application uses as a resource (database, queueing systems, email, cache) should be referenced with “bindings” to these services.
Backing services should be called via an API.
5. Build, release, run
Strictly separate build and run stages
Don’t compile on production environment.
Blue/Green Deployments are a rule, not an exception.
Execute the app as one or more stateless processes
Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis.
7. Port binding
Export services via port binding
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown.
Processes shut down gracefully when they receive a SIGTERM signal from the process manager.
10. Dev/prod parity
Keep development, staging, and production as similar as possible.
The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.
Dev MUST == Production in config, but not performance
Treat logs as event streams
A twelve-factor app never concerns itself with routing or storage of its output
stream. It should not attempt to write to or manage logfiles. Instead, each
running process writes its event stream, unbuffered, to
12. Admin processes
Run admin/management tasks as one-off processes.
Twelve-factor strongly favors languages which provide a REPL shell out of the box, and which make it easy to run one-off scripts. In a local deploy, developers invoke one-off admin processes by a direct shell command inside the app’s checkout directory. In a production deploy, developers can use ssh or other remote command execution mechanism provided by that deploy’s execution environment to run such a process.