Introduction to the

The 12-Factor provides a methodology for building SaaS applications that:

  • Use a standardized process to automate configuration so that new developers can join the project with minimal learning costs.
  • Keep the boundaries as clear as possible between operating systems and provide maximum portability across systems.
  • Suitable for deployment on modern cloud computing platforms to save resources in server and system administration.
  • Minimize differences between development and production environments and implement agile development using continuous delivery. = Extensions can be implemented without significant changes to the tools, architecture, and development process.

1. Benchmark code

Although there is only one base code for each application, multiple deployments can exist simultaneously. Each deployment is equivalent to running an instance of an application.

2, rely on

Explicitly declaring dependencies simplifies the environment configuration process for new developers. A new developer can check out the application’s benchmark code, install the programming language and its dependency management tools, install all the dependencies with a single build command, and get to work.

3, configuration,

The configuration of a storage configuration application in an environment can vary greatly between deployments (pre-release, production, development, and so on). Environment variables can be easily changed between deployments without touching a line of code; Unlike configuration files, the chance of accidentally checking them into the code base is minimal; In contrast to some traditional mechanisms for solving configuration problems, such as Java’s property configuration files, environment variables are language – and system-independent.

4. Back-end services

Backing services as an additional resource. Back-end services are the various services that are invoked over the network to run the program, such as databases (MySQL, CouchDB), message/queue systems (RabbitMQ, Beanstalkd), SMTP mail delivery services (Postfix), and Memcached systems. For the application, the data is retrieved through a URL or other service location/service certificate stored in the configuration. Any deployment of the 12-Factor application should be able to replace the local MySQL database with a third-party service (such as Amazon RDS) without any code changes.

Build, publish, run

The transformation of benchmark code into a deployment (non-development environment) requires three phases:

  • The construction phase refers to the process of converting a code repository into an executable package. The build uses the code of the specified version, gets and packages dependencies, and compiles them into binaries and resource files.
  • The release phase combines the results of the build with the configuration required for the current deployment and is immediately available for use in the runtime environment.
  • The run phase (or “run time”) is the start of a series of application processes in the execution environment for a selected release.

6, processes,

Running applications with one or more stateless processes Any data that needs to be persisted is stored in back-end services, such as databases. The data in the Session should be stored in a cache with an expiration date such as Memcached or Redis.

7. Port bonding

Internet applications use Port binding to provide services and listen for requests sent to the Port. In the local environment, the developer accesses the service through an address like http://localhost:5000/. In an online environment, requests are uniformly sent to a public domain and then routed to a network process bound to a port.

8, concurrent

Extension through the process model to assign different work to different process types. For example, HTTP requests can be handed over to web processes, while resident background work is handed over to worker processes.

9, easy to handle

Processes that quickly start and gracefully terminate 12-factor applications to maximize robustness are disposable, meaning they can be started or stopped instantly. This facilitates fast, resilient scaling applications, rapid deployment of changing code or configuration, and robust deployment of applications. Processes should aim for minimum startup time. A process terminates gracefully once it receives a SIGTERM.

10. The development environment is equivalent to the online environment

Keep development, pre-release, and online environments the same as much as possible. For 12-factor apps to continue to deploy, they must bridge the gap between local and online. Go back to the three differences described above:

  • Narrow the time gap: Developers can deploy code in hours, even minutes.
  • Close the human divide: Developers should not only write code, but also be intimately involved in the deployment process and how the code behaves online.
  • Narrow tool differences: Try to ensure consistency between the development environment and the online environment.

11, logs,

The log should be a summary of the flow of events, gathering the output streams of all running processes and back-end services in chronological order. The original format of a log is really an event line, although you may need to look at many lines when looking back at a problem.

12. Manage the process

Background administrative tasks run as one-off processes One-off administrative processes should use the same environment as normal resident processes. These administrative processes use the same code and configuration as any other process and run on a release. The admin code should be distributed with other application code to avoid synchronization problems.