12 Factor Apps

Last updated: Dec 4, 2022 17:08:50

An app’s config is everything that is likely to vary between  deploys

A  deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as  Amazon RDS) without any changes to the app’s code…  only the resource handle in the config needs to change.

A  codebase is transformed into a (non-development) deploy through three stages:

• The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches vendors  dependencies and compiles binaries and assets.
• The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.
• The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’s  processes against a selected release.

Every release should always have a unique release ID, such as a timestamp of the release (such as 2011-04-06-20:32:17) or an incrementing number (such as v100). Releases are an append-only ledger and a release cannot be mutated once it is created. Any change must create a new release.

The twelve-factor app never assumes that anything cached in memory or on disk will be available on a future request or job

• use the same type and version of backing service in development and production (all instances of deployment) - e.g. do not use sqlite in dev and postgresql in prod, even though they have the same interface (=ORM in this case)
• use docker