The 1200-factor app. Extending the twelve-factor app with more advanced conciderations.
One codebase tracked in revision control, many deploys
Explicitly declare and isolate dependencies
Store config in the environment
Treat backing services as attached resources
Strictly separate build and run stages
Execute the app as one or more stateless processes
Export services via port binding
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown
Keep development, staging, and production as similar as possible
- Nothing is harder than to accomodate for N apps in M environments
- Automate the configuration of environments to avoid snowflakes
Treat logs as event streams
- Logs must be treated so that records can be lost - mission critical events does not belong in a log
Run admin/management tasks as one-off processes
Determine which key metrics your domain is concerned with
Deploy critical functionality behind feature toggles
-
To ensure safe deployment, use feature toggles for new or existing features
-
Feature toggles can also be used to deploy functionality to a given subset of all users, e.g. 5%.
Minimize the local development machine config needed to run the app
-
Manual config to set up the development environment to start the app locally should be kept at a minimum to not pollute the development the machine used
-
This can either be solved by using virtualization technology such as VirtualBox or container technology such as Docker
Use a login provider that your target audience is a member of
- Examples are Facebook, Google and Twitter
Aim to create stateless applications and services
- Storing application state in the application makes it difficult to redeploy. If possible, it should be stored in a database or similar.
Make your apps as similar to other apps in the same sphere as possible.
- Always include a ./bin/start script or similar
- Don't rely on people to run very specific commands from the command line