Read on Twitter
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
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:
Codebase
Dependencies
Config
Backing services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
CodebaseDependenciesConfigBacking servicesBuild, release, runProcessesPort bindingConcurrencyDisposabilityDev/prod parityLogsAdmin processes
CodebaseA 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
DependenciesExplicitly 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).
ConfigStore 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.
Backing servicesTreat backing services as attached resources
The code for a twelve-factor app makes no distinction between local and third party services.
Build, release, runStrictly 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 it with the deploy’s config.
- RUN: runs the app in the exec environment.
ProcessesExecute 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.
Port bindingExport 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.
ConcurrencyScale-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.
DisposabilityMaximize 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.
Dev/prod parityKeep 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
LogsTreat 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.
Admin processesRun 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:
Codebase
Dependencies
Config
Backing services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
The Twelve Factors:
CodebaseDependenciesConfigBacking servicesBuild, release, runProcessesPort bindingConcurrencyDisposabilityDev/prod parityLogsAdmin processes
Source:
https://12factor.net/
https://12factor.net/
