The Twelve-Factor App is a methodology for building software-as-a-service (SaaS) applications. It is versatile, applicable to any programming language, and supports various backing services such as databases, queues, and caches.

By following the Twelve-Factor principles, developers can create robust, scalable, and maintainable applications. These practices ensure easy deployment, management, and scaling, while simplifying collaboration and maintaining consistency across environments.

Ideal for both simple web apps and complex systems, the Twelve-Factor methodology enhances the development lifecycle and operational efficiency, ensuring applications can adapt to changes in scale and complexity.

For more information, visit the official Twelve-Factor App site

I. Codebase

A codebase is a single repository or a set of repositories that share a common root. There is always a one-to-one correlation between a codebase and an application:

Monorepo: A single repository contains the entire application. This centralizes the codebase, simplifying management and versioning, especially when components are interdependent.
Multi-repo: Each repository contains an independent application. This allows each app within a distributed system to have its own codebase and be managed separately. Shared code should be placed in libraries included via dependency managers.

In the Twelve-Factor App context, each application must be independent. Thus, two Flutter apps cannot depend directly on each other. Instead:

App A and App B can share common code through a separate library/package.
Both apps can then depend on this library/package.

There is only one codebase per application, but multiple deployments of it. The codebase remains consistent across all deployments, though different versions might be active in production, staging, or development environments.

II. Dependencies

A twelve-factor app must explicitly declare and isolate its dependencies without assuming the presence of any system-wide software. This includes libraries, packages, or any other components necessary to run the application.

Principles:

Explicit Declaration: All dependencies must be listed and managed through an appropriate package manager (e.g., pubspec.yaml for Dart/Flutter applications).
Isolation: Avoid global system dependencies. Each dependency should be installed locally within the application’s context.

Additionally, one of the key benefits of explicit dependency declaration is the ease of setting up the development environment for new developers. By simply running the dependency manager, they can reproduce the environment quickly and efficiently.

III. Config

Configuration of an application encompasses everything that is likely to vary between deployments (staging, production, development environments, etc.).

Applications might store configurations in the code as constants. This approach violates the Twelve-Factor principles, as it demands a strict separation between code and configuration. Configuration varies significantly across deployments, whereas code does not.

A twelve-factor app stores configuration in environment variables (often abbreviated as env vars or env).

In the context of Flutter, it is not recommended to use packages like “dot-env”, as they pose a security risk by exposing credentials to the end user;
Instead, use the --dart-define option for this purpose.

IV. Backing Services

A backing service is any service the app consumes over the network as part of its normal operation.

E.g: Data stores (MySQL or PostgreSQL), Mssaging/Queueing Systems (Kafka or RabbitMQ), Caching Systems, SMTP services, etc.

Backing services can be local or third-party. For example, a local database is one you create and manage locally, whereas a service like Loggly is third-party. The code of a twelve-factor app makes no distinction between local and third-party services.

To the app, both are attached resources, accessible via a URL or other locator/credentials in the config. A twelve-factor app deployment should be able to swap a local MySQL database for a managed service like Amazon RDS without any changes to the app’s code.

V. Build, Release, Run

A codebase is transformed into a non-development deployment through three stages:

The build stage is a transformation that converts a code repository into an executable package known as a build.
The release stage takes the build produced by the build stage and combines it with the current configuration of the deployment.
The run stage runs the app in the execution environment (e.g., PlayStore and AppStore).

Releases are append-only ledger entries, meaning once a release is created, it cannot be modified. Any change must generate a new release.

This clear separation between build, release, and run stages helps ensure consistency, problem isolation, and flexibility in maintaining and scaling applications. It allows developers to reproduce and debug issues effectively by isolating each stage of the deployment process.

Builds are initiated from the codebase and create an immutable artifact.
Releases are append-only ledger entries, meaning once a release is created, it cannot be modified. Any change must generate a new release, ensuring traceability and reliability.
Runs are instances of the application executing in the deployment environment, leveraging the configured release.

By maintaining this strict separation, teams can confidently push updates, roll back changes, and manage environments with greater control and predictability, enhancing collaboration and agility across development, operations, and QA.

VI. Proccesses

Running the application as stateless and ephemeral processes allows it to be easily scalable and resilient, simplifying management and fault recovery.

Principles:

Stateless Processes: Processes should not share state. This facilitates horizontal scaling and enhances the resilience of the application.
External State Management: Persistent state should be maintained in external services (such as databases and caches), while temporary state should reside in the process’s memory.
Isolated Process: Different types of processes (e.g., web servers, workers) should be isolated to ensure that failures in one type do not affect others.

VII. Port Binding

A twelve-factor app must be completely self-contained, including its own web server. This means the application does not depend on an external web server to function; it brings its own integrated server.

Principles:

Self-Contained Applications: Each application should include its own web server. This ensures the app does not rely on an external server for functionality, making it self-sufficient.
Listening on Specific Ports: The application should listen for connections on a specific port. This port is configured by the environment where the application is running, typically through environment variables.
Configurable Ports: The port on which the application listens should be configurable, allowing the same application to run in different environments (development, testing, production) without changing the code.

By adhering to the port binding principle, applications become more flexible and maintainable, ensuring consistent behavior across various environments and simplifying the deployment process.

VIII. Concurrency

Concurrency addresses how to handle increased demand and scalability of applications. The core idea is to scale the application by running multiple processes instead of using threads within a single process.

Principles:

Multiple Process Types: Each type of workload (such as handling HTTP requests or performing background tasks) is managed by a specific type of process, following the UNIX process model. This allows for horizontal scalability by adding more instances of these processes as needed.
Independent Scaling: Different processes can be scaled independently based on the specific needs of the workload, ensuring efficient use of resources and better performance.

IX. Disposability

The “Disposability” section of The Twelve-Factor App focuses on the robustness and resilience of an application, ensuring that processes can be started and stopped quickly and gracefully. Here are the key points:

Principles:

Quick Startup: Processes should start up quickly, minimizing the time between the start command and the process being ready to handle requests.
Graceful Shutdown: Processes should be able to shut down gracefully, releasing resources and completing ongoing tasks before stopping. This prevents data loss or corruption.
Facilitates Horizontal Scalability: The ability to start and stop processes quickly allows for horizontal scalability, adding or removing instances as needed to meet demand.

X. Dev/Prod Parity

This section emphasizes the importance of minimizing differences between development, testing, and production environments. The main points are:

Principles:

Minimize Deployment Time: Reduce the time between writing code and deploying it to production. Continuous deployment practices help keep the application constantly evolving.
Unified Responsibility: Developers who write code should also manage the production environment, this promotes a better understanding of operations
Consistency Across Environments: Use the same tools and processes in all environments. This includes configurations, libraries, dependency versions, etc.
Replicable Environments: Ensure that an environment is replicable between development and production. Using Infrastructure as Code (IaC) is a viable approach for achieving this.

In summary, the practice of “Dev/Prod Parity” ensures that development, testing, and production environments are as similar as possible, promoting higher quality, agility, and efficiency in software delivery.

XI. Logs

The “Logs” section of The Twelve-Factor App addresses how an application should manage its logs. Logs are essential for monitoring application behavior, debugging issues, and understanding event history. Here are the key points:

Principles:

Treat Logs as Event Streams: The application should treat log generation as a continuous event stream. These events can be emitted to stdout or stderr output.
Decouple Log Destinations: The application should not be concerned with log storage or management. Instead, it should only emit log events. The execution environment should capture these events and route them to appropriate storage or analysis systems.
Emit to stdout and stderr: Emitting logs to stdout and stderr facilitates integration with various aggregation tools, such as the ELK Stack (Elasticsearch, Logstash, Kibana).

By adhering to the logging principle, applications can ensure that log management is flexible, efficient, and easily adaptable to different environments and requirements.

XII. Admin Processes

The “Admin Processes” section of The Twelve-Factor App addresses how to perform administrative and maintenance tasks in an application. Here are the key point

Principles:

Run as One-off Processes: Administrative tasks, such as database migrations, cache clearing, or diagnostic operations, should be executed as one-off processes, isolated from the main application lifecycle.
Consistent Execution Environment: These admin processes should run in the same environment as the application, using the same codebase and configuration. This ensures consistency and predictability in the execution of these tasks.

The Twelve-Factor App methodology recommends that administrative and maintenance tasks be executed as one-off processes in an isolated, consistent environment. This practice ensures that these tasks are reliable, automatable, and do not disrupt the main application.

Conclusion

The Twelve-Factor App methodology provides a robust framework for building scalable and maintainable applications. By following its principles, developers can ensure their applications are resilient, easy to deploy, and manage across different environments.

Key practices such as explicit dependency declaration, environment parity, and treating logs as event streams simplify configuration, enhance collaboration, and promote agile development. The separation of build, release, and run stages guarantees consistency and reliability.

Implementing the Twelve-Factor principles helps organizations create modern, adaptable applications that can handle evolving requirements and scale effortlessly.