The Twelve-Factor App🧵

A methodology for building SAAS that:

🔹Use declarative formats for automation
🔹Have a clean contract with the OS
🔹Are suitable for deployment on modern platforms
🔹Minimize divergence between dev and prod
🔹Can scale up without significant changes
The Twelve-Factor App A methodology for building SAAS that:Use declarative formats for automationHave a clean contract with the OSAre suitable for deployment on modern platformsMinimize divergence between dev and prodCan scale up without significant changes
The Twelve-Factor App A methodology for building SAAS that:Use declarative formats for automationHave a clean contract with the OSAre suitable for deployment on modern platformsMinimize divergence between dev and prodCan scale up without significant changes
The Twelve-Factor App A methodology for building SAAS that:Use declarative formats for automationHave a clean contract with the OSAre suitable for deployment on modern platformsMinimize divergence between dev and prodCan scale up without significant changes
The Twelve-Factor App A methodology for building SAAS that:Use declarative formats for automationHave a clean contract with the OSAre suitable for deployment on modern platformsMinimize divergence between dev and prodCan scale up without significant changes
The Twelve Factors:

1⃣Codebase
2⃣Dependencies
3⃣Config
4⃣Backing services
5⃣Build, release, run
6⃣Processes
7⃣Port binding
8⃣Concurrency
9⃣Disposability
1⃣0⃣Dev/prod parity
1⃣1⃣Logs
1⃣2⃣Admin processes
1⃣Codebase

A 12-factor app is always tracked in a version control system, such as Git.

One codebase, many deploys.

A copy of the revision tracking database is known as a code repository.

There is always a 1-to-1 correlation between the codebase-app
2⃣Dependencies

Explicitly declare and isolate dependencies.

A 12-factor app never relies on the implicit existence of system-wide packages.

12-factor apps also do not rely on the implicit existence of any system tools (for example curl).
3⃣Config

Store config in the environment.

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

The twelve-factor app stores config in environment variables.
4⃣Backing services

Treat backing services as attached resources

The code for a twelve-factor app makes no distinction between local and third party services.
5⃣Build, release, run

Strictly separate build and run stages.

A codebase is transformed into a deploy.

Three STAGES:
- BUILD: converts a repo into an executable (build).
- RELEASE: combines the build with the deploy’s config.
- RUN: runs the app in the exec environment.
6⃣Processes

Execute the app as one or more stateless processes.

The app is executed in the execution environment as one or more processes.

Any data that needs to persist must be stored in a stateful backing service, typically a database.
7⃣Port binding

Export services via port binding.

The twelve-factor app is completely self-contained.

The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
8⃣Concurrency

Scale-out via the process model.

In the twelve-factor app, processes are a first-class citizen.

Processes in the twelve-factor app take strong cues from the Unix process model for running service daemons.
9⃣Disposability

Maximize robustness with fast startup and graceful shutdown.

The app’s processes are disposable, they can be started/stopped at a moment’s notice.

Processes should:
- strive to minimize startup time.
- shut down gracefully.
- be robust against sudden death.
1⃣0⃣Dev/prod parity

Keep dev, staging, and production as similar as possible

The 12-factor app is designed for continuous deployment, keeping the gap between dev and prod small.

The 12-factor dev resists the urge to use different backing services between dev/prod
1⃣1⃣Logs

Treat logs as event streams.

A 12-factor app never concerns itself with routing/storage of its output stream. No logfiles.

Each process writes its unbuffered event stream to stdout.

During dev stream in the terminal to observe the app’s behavior.
1⃣2⃣Admin processes

Run admin/management tasks as one-off processes.

The process formation is the array of processes that are used to do the app’s regular business (such as handling web requests) as it runs.
Recap:

The Twelve Factors:

1⃣Codebase
2⃣Dependencies
3⃣Config
4⃣Backing services
5⃣Build, release, run
6⃣Processes
7⃣Port binding
8⃣Concurrency
9⃣Disposability
1⃣0⃣Dev/prod parity
1⃣1⃣Logs
1⃣2⃣Admin processes
Source:
https://12factor.net 
You can follow @FrancescoCiull4.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:
Those who think consciousness raising & movement building are disconnected, or even a distraction from electoral politics have not paid attention to the history of social change.In this thread, we
Read more
The 2020s will be known as the Remote Work decadeA few predictions of what is likely to emerge[ a thread ] Third Space: Office and Working from Home will
Read more
1/29: Have you ever had a concept explained to you that helps frame complex issues you’ve been wrestling with and opens your eyes to new possibilities? A concept that I
Read more
By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.