The Twelve-Factor App

the twelve-factor app is a set of recommendations from 2011 that are based less on engineering principles and more on the capabilities of Heroku and containerized infrastructure in 2011. For example: > Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a…

This is a very excellent list, and reads almost exactly how I've documented my personal standards and best practices. There are a few things that I feel are left out, and should definitely be just as important: 1. Testing. Having automated tests that your developers are ideally writing first makes a world of difference. Throw it into your continuous integration system, and nurture a culture around it. If your tools and language allow it, having a lint or style checker…

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

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…