The Twelve-Factor App

 The Twelve-Factor App (12 Factor App):

1. Codebase: 

One Revison Control System for entire codes. All codes related to an application (eg. source code, scripts, configuration settings) are stored in source code repository. This should be accessible for development, testing, system administration stuffs. This also accessible to all automation scripts that are part of Continuous Integration/Continuous Delivery (CI/CD) processes that are part of the enterprise's Software Development Lifecycle (SDLC).

2. Dependencies:

Explicitly declare and isolate dependencies, avoid storing artifacts along with source code in the source code repository. Only code that is unique and relevant to the purpose of the application is stored in source control and any external artifacts/dependencies (eg. node.js, java.jr) should be referenced in a dependencies manifest. So that ii will be loaded accessed and loaded into memory at development, testing and production runtime.

3. Config:

Store Configuration as environment, the "Config" principle states that configuration information is injected into the runtime environment as "environment variables" or as settings defined in an independent configuration file. The benefit of keeping configuration settings separate from application code is that you can apply configuration settings according to the type of the deployment. For example, you can have one set of configuration settings for a deployment intended for a testing environment and a different set for a deployment designed for a production environment.

4. Backing Services:

Treat backing services as attached resources, the "Backing Services" principle encourages architects "to treat external components" such as databases, email servers, message brokers, and independent services that can be provisioned and maintained by systems personnel "as attached resources". Treating resources as backing services promotes flexibility and efficiency in the software development lifecycle (SDLC).

5. Build, Release, Run:

Strictly separate build and run stages, the principle of "Build, Release, and Run" breaks the deployment process down into three stages that can be instantiated at any time. 

Build stage --> code is retrieved from the source code management system and built/compiled.

Release Stage --> After the code is built, configuration settings are applied in the Release stage. 

Run stage --> A runtime environment is provisioned via scripts using a tool such as Ansible. The application and its dependencies are deployed into the newly provisioned runtime environment.

Note: The process is completely ephemeral between Build, Release, and Run. If anything in the pipeline destroyed, all artifacts and environments can be reconstituted from scratch using assets stored in the source code repository.

6. Processes:

Execute the app as one or more stateless processes, we can call it as "Stateless" processes. An application developed under The 12 Factor App structure will run as a collection of stateless processes. This means that no single process keeps track of the state of another process. Scaling is easier in Stateless process, instances can be added and removed to address a particular load burden at a given point in time.

7. Port Binding:

Export services via port binding, the principle of "Port Binding" asserts that a service or application is identifiable to the network by port number, not a domain name. The essential idea behind the principle of port binding is that the uniform use of a port number is the best way to expose a process to the network. For example, the patterns have emerged in which port 80 is conventional for web servers running under HTTP, port 443 is the default port number for HTTPS, port 22 is for SSH, port 3306 is the default port for MySQL, and port 27017 is the default port for MongoDB.

8. Concurrency: 

The principle of "Concurrency" recommends organizing processes according to their purpose and then separating those processes so that they can be scaled up and down according to requirement. Supporting concurrency means that different parts (webserver layer, app server layer, db layer) of an application can be scaled up in an isolated manner to meet the demands.

9. Disposability:

Maximize robustness with fast startup and graceful shutdown, the principle of "Disposability" asserts that applications should start and stop gracefully. This means doing all the required "housekeeping" before an application is made accessible to consumers. 

A graceful startup will ensure that all database connections and access to other network resources are operational.

A graceful shutdown will ensure that all database connections and other network resources are terminated properly and that all shutdown activity is logged.

10. Dev/Prod Parity:

Keep development, staging, and production as similar as possible, the Dev/Prod Parity principle means all deployment paths are similar yet independent. 

Consider, the V1 version is targeted for release to the Production environment and the V2 version is targeted for release to the Development environment. Both V1 and V2 follow a similar deployment path, from Build to Release and then Run. By following this principle, we no need to copy the V2 version to production deployment (when it needs) instead we can configure the CI/CD process to set V2 version for the production.

11. Logs:

Treat logs as event streams, the "Logs" principle advocates sending log data in a stream that a variety of interested consumers can access. Kind of filtering and sending to appropriate consumer. For example, one consumer might only be interested in Error data, while another consumer might be interested in Request/Response data. The benefit is that even if an app dies, the log data lives on well afterward.

12. Admin Processes:

Run admin/management tasks as one-off processes, the principle of "Admin Processes" states that admin processes are first-class citizens in the software development lifecycle and need to be treated as such.