Joshua T Kalis (he/him/his)

I build great teams and excellent software.

Twelve-Factor Apps

A set of broad conceptual solutions, and a shared vocabulary, for systemic problems seen in modern application development.


Twelve-Factor Apps

A set of ideal app development practices to isolate concerns well enough to make them configurable for future flexibility with minimal changes.


The Twelve Factors

  1. Codebase - One codebase tracked in revision control, many deploys
  2. Dependencies - Explicitly declare and isolate dependencies
  3. Config - Store config in the environment
  4. Backing Services - Treat backing services as attached resources
  5. Build, Release, Run - Strictly separate build and run stages
  6. Processes - Execute the app as one or more stateless processes
  7. Port Binding - Export services via port binding
  8. Concurrency - Scale out via the process model
  9. Disposability - Maximize robustness with fast startup and graceful shutdown
  10. Dev/Prod Parity - Keep development, staging, and production as similar as possible
  11. Logs - Treat logs as event streams
  12. Admin Processes - Run admin/management tasks as one-off processes

Original work available: https://12factor.net/


Groups

  1. Code
    1. Codebase
    2. Dependencies
    3. Config
    4. Backing Services
  2. Deploy
    1. Build, Release, Run
    2. Processes
    3. Port Binding
    4. Concurrency
  3. Operate / Run
    1. Disposability
    2. Dev/Prod Parity
    3. Logs
    4. Admin Processes

Aditya Satrya


Groups (cont.)

  1. What you do
    1. Codebase
    2. Dependencies
    3. Config
    4. Backing Services
    5. Build, Release, Run
  2. What you get
    1. Processes
    2. Port Binding
    3. Concurrency
    4. Disposability
    5. Dev/Prod Parity
  3. Monitoring
    1. Logs
    2. Admin Processes

1. Codebase (noun)

There is one and only one codebase for an app and an app has only one codebase. This is the source of truth for what is "the app". The codebase ties everything together.

All of this SHOULD be version controlled in some way and kept together.


2. Dependencies (verb)


3. Config (noun)

These are the "variables" that are likely to change between deployments/environments (dev, test, beta, prod, etc). Some obvious examples are:

The - environment - config variables are the secrets that make the app work in the environments they will be deployed to; including locally on a developers machine.

These values (above) should not be stored in the Codebase.

Other values - that are not secret - can be stored in Codebase config files.


4. Backing Services (noun)

These are the resources that enable the Twelve-factor App to function but are "larger", or more generic, than the just the app. Similar Backing Services should be considered/treated as interchangeable without needing changes in the Codebase; e.g. multiple SMTP (email) services.

If a capability is not core to the purpose of the app it should likely be treated as a Backing Service and therefor externalized in the same way.

Access to Backing Services should be achieved through Config values consumed and used at runtime by the app.


5. Build, Release, Run (verbs)

  1. Build
    • The fetching and bundling of defined Dependencies and compiled code - from the Codebase - into a single unit; a build artifact: dmg, exe, jar/war, tar, zip, etc.
    • This build artifact is environment independent; it should be able to run in any environment without changes needing to be made to anything inside of it
  2. Release
    • The combination of the "build", "artifact", or "build artifact" with all of the Config for a given environment in the runtime environment: container, server, whatever
  3. Run
    • The phase/stage when an app is running in an environment

6. Processes


7. Port Binding

A Twelve-factor App will include everything needed to handle requests coming from ports and will indicate which ports it is expecting to receive requests through.


8. Concurrency


9. Disposability

Any single instance of a Twelve-factor App should not assume that it will be successful; software "bugs", or hardware failures can cause Processes to fail. Since success is never a guarantee failure must always be planned for.


10. Dev/Prod Parity


11. Logs


12. Admin Processes


Joshua T Kalis

Jan 2022