The Twelve Factor App is something I came across that a while ago that resonates with my thought process. It’s primarily for software-as-a-service applications but so much of it can be abstracted to be applied to many other forms of systems.
What really rings through is that the version of code in source control is the live version, config is stored in the environment and logging is just a stream to standard out to be consumed as needed. Implementing these alone get a development team to a stage where an application can be deployed from git/svn/other to any environment be it production/staging or just a developers laptop with one click.
Does it work? Yes, I've been doing it for years!
###I. Codebase
One codebase per app tracked in revision control and can be deployed to many environments
###II. Dependencies
Explicitly declare and isolate dependencies. If you have binary dependencies check them in and make them part of the application. It's *Version Control* not *Source Control*
###III. Config
Store config in the environment - don't tie your repository to a specific configuration.
###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 - managing threads is hard. Processes are free.
###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 - other services like *Splunk* can consume them.
###XII. Admin processes
Run admin/management tasks as one-off processes. This is just cost efficient.
The full article is available on [http://12factor.net/](http://12factor.net/) and is worth a read.
28 Jan 2014
John Ryan
practices development methodologies