🔗The Twelve Factors

🔗1. Codebase

Everything in revision control including environment configuration

git flow master - production develop - staging

🔗2. Dependencies

Explicitly declare and isolate dependencies

🔗3. Config

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.

🔗6. Processes

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

🔗8. Concurrency

Scale out via the process model

🔗9. Disposability

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

🔗11. Logs

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 stdout.

🔗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.

{{< youtube GZ4sAEUMOnM>}}