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.
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).
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
———
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
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).