
The Twelve-Factor App - oli5679
https://12factor.net/
======
nine_k
They give a nice TOC:

———

The Twelve Factors

I. Codebase: One codebase tracked in revision control, many deploys

II. Dependencies: Explicitly declare and isolate dependencies

III. Config: Store config in the environment

IV. Backing services: Treat backing services as attached resources

V. Build, release, run: Strictly separate build and run stages

VI. Processes: Execute the app as one or more stateless processes

VII. Port binding: Export services via port binding

VIII. Concurrency: Scale out via the process model

IX. Disposability: Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity: Keep development, staging, and production as similar as
possible

XI. Logs: Treat logs as event streams

XII. Admin processes: Run admin/management tasks as one-off processes

———

------
rahimnathwani
Just as with yesterday's discussion about Black[0], there will be people who
like 83% and dislike the other 17%. But having stated principles about how you
build software within your organisation ought to make everyone's life easier
and more enjoyable.

And this list is a great starting point, even if your organisation chooses to
adopt precisely the opposite for each of the 12 points.

[0]
[https://news.ycombinator.com/item?id=19939806](https://news.ycombinator.com/item?id=19939806)

------
thomascgalvin
I've worked on codebases designed using this model, and it's a vast
improvement over how many web service applications are created. A lot of this
seems like common sense (one codebase, for example), and some of it is
frustratingly _uncommon_ sense (like dev/prod parity).

