1. Reference
   1. https://12factor.net/
2. Codebase
   1. one codebase tracked in revision control, many deploys
      1. one-to-one correlation between the codebase and the app
         1. Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the dependency manager.
         2. If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor.
      2. deploys
         1. production
         2. stage
         3. inner testing
         4. developer1
         5. developer2
      3. The codebase is the same across all deploys, although different versions may be active in each deploy.
3. Dependencies
   1. Explicitly declare and isolate dependencies
      1. packaging system
      2. A twelve-factor app never relies on implicit existence of system-wide packages.
         1. dependency declaration manifest
            1. pip
         2. dependency isolation tool
            1. dependency isolation tool
            2. dependency isolation tool
            3. Virtualenv
      3. dependency declaration and isolation must always be used together
      4. Twelve-factor apps also do not rely on the implicit existence of any system tools
         1. curl
         2. ImageMagick
4. Config
   1. Store config in the environment
      1. includes
         1. Resource handles to the database, Memcached, and other backing services
         2. Credentials to external services such as Amazon S3 or Twitter
         3. Per-deploy values such as the canonical hostname for the deploy
      2. strict separation of config from code. Config varies substantially across deploys, code does not.
      3. config is the use of config files which are not checked into revision control
         1. database settings
      4. The twelve-factor app stores config in environment variables
      5. Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly
      6. env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy.
5. Backing services
   1. Treat backing services as attached resources
      1. A backing service is any service the app consumes over the network as part of its normal operation.
         1. datastores
            1. mysql
         2. messaging/queueing sytem
            1. RabbitMQ
         3. SMTP
            1. Postfix
         4. caching system
            1. redis
      2. services provided and managed by third parties
         1. SMTP
            1. PostMark
         2. metrics-gathering
            1. New Relic
         3. binary asset
            1. Amazon S3
         4. API
            1. Twitter
            2. Google Maps
      3. no distinction between local and third party services.
         1. accessed via a URL or other locator/credentials stored in the config.
         2. 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.
         3. only the resource handle in the config needs to change.
         4. app and resources loose coupling to the deploy they are attached to.
6. Build, release, run
   1. Strictly separate build and run stages
      1. stages
         1. build
            1. converts a code repo into an executable bundle known as a build.
            2. fetches vendors dependencies and compiles binaries and assets.
         2. release
            1. takes the build produced by the build stage and combines it with the deploy’s current config.
         3. run
            1. runs the app in the execution environment, by launching some set of the app’s processes against a selected release.
      2. it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage.
      3. Deployment tools typically offer release management tools, most notably the ability to roll back to a previous release.
         1. Capistrano
      4. Every release should always have a unique release ID
      5. the run stage should be kept to as few moving parts as possible
7. Processes
   1. Execute the app as one or more stateless processes
   2. processes are stateless and share-nothing.
   3. Any data that needs to persist must be stored in a stateful backing service
   4. never assumes that anything cached in memory or on disk will be available on a future request or job
   5. prefer to use the filesystem as a cache for compiled assets during the building stage, rather than at runtime.
   6. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis.
8. Port binding
   1. Export services via port binding
      1. completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service.
      2. one app can become the backing service for another app.
9. Concurrency
   1. Scale out via the process model
      1. processes are a first class citizen.
      2. the developer can architect their app to handle diverse workloads by assigning each type of work to a process type.
         1. HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process.
      3. an individual VM can only grow so large (vertical scale), so the application must also be able to span multiple processes running on multiple physical machines.
      4. The array of process types and number of processes of each type is known as the process formation.
      5. processes should never daemonize or write PID files.
      6. App should rely on the operating system’s process manager to manage output streams, respond to crashed processes, and handle user-initiated restarts and shutdowns.
10. Disposability
    1. Maximize robustness with fast startup and graceful shutdown
       1. Processes should strive to minimize startup time.
       2. Processes shut down gracefully when they receive a SIGTERM signal from the process manager.
          1. Web Process
             1. ceasing to listen on the service port (thereby refusing any new requests), allowing any current requests to finish, and then exiting.
          2. long polling
             1. the client should seamlessly attempt to reconnect when the connection is lost.
          3. worker process
             1. returning the current job to the work queue.
       3. Processes should also be robust against sudden death
11. Dev/prod parity
    1. Keep development, staging, and production as similar as possible
       1. gaps between development and production
          1. the time gap
             1. A developer may work on code that takes days, weeks, or even months to go into production.
             2. a developer may write code and have it deployed hours or even just minutes later.
          2. the personnel gap
             1. Developers write code, ops engineers deploy it.
             2. developers who wrote code are closely involved in deploying it and watching its behavior in production.
          3. the tools gap
             1. Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux.
             2. keep development and production as similar as possible.
             3. using library to be an adapter for different backing services from development and production
       2. resists the urge to use different backing services between development and production
       3. using packaging system, declarative provisioning tools, and virtual environment to build local environment close with production environment.
       4. all deploys of the app should be using the same type and version of each of the backing services.
12. Logs
    1. Treat logs as event streams
       1. never concerns itself with routing or storage of its output stream.
          1. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout.
       2. staging or production deploys
          1. each process’ stream will be captured by the execution environment
          2. ollated together with all other streams from the app
          3. routed to one or more final destinations for viewing and long-term archival
          4. destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment.
          5. example
             1. Logplex
             2. Fluent
       3. log analysis
          1. example
             1. log indexing and analysis system
             2. splunk
             3. data warehousing system
             4. Hadoop
             5. Hive
          2. Finding specific events in the past
          3. Large-scale graphing of trends (such as requests per minute)
          4. Active alerting according to user-defined heuristics (such as an alert when the quantity of errors per minute exceeds a certain threshold)
13. Admin Processes
    1. Run admin/management tasks as one-off processes
       1. one-off tasks
          1. Running database migrations
          2. Running a console
             1. run arbitrary code
             2. inspect the app’s models against the live database
          3. Running one-time scripts committed into the app’s repo
       2. One-off admin processes should be run in an identical environment as the regular long-running processes of the app.
          1. Admin code must ship with application code to avoid synchronization issues.
       3. The same dependency isolation techniques should be used on all process types.
       4. strongly favors languages which provide a REPL shell out of the box