The Twelve-Factor App

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