In modern era, software is commonly delivered as a service, called web app, or software as a service. The twelve-factor app is a methodology for building software-as-a-service.
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project.
The Twelve Factors
- Codebase: One codebase, one application. Build on top of one codebase, fully tracked by version control system. Deployments should be automatic, so everything can run in different environments without work. You should always have one repository for an individual application to ease CI/CD pipelines.
- Dependencies: You should use a dependency management system, and isolate your application dependencies. Always remember to use correct versions of dependencies so that all environments are in sync and produce the same behavior.
- Config: All configuration and credentials are stored as environment variable. This removes any vulnerability that could come from exposing sensitive credential in your code and also allows you to control all configuration from command line, making it possible to automate deploys. There should be a strict separation between config and code. The code should remain the same irrespective of where the application is being deployed, but configurations can vary.
- Backing Services: Treat backing services as attached resources as your services should be easily interchangeable. You must be able to easily swap the backing service from one provider to another without code changes. This will ensure good portability to help maintain your system.
- Build, Run, Release: A twelve-factor application requires a strict separation between Build, Release and Run stages. Every release should always have a unique release ID and releases should allow rollback. Automation and maintaining the system should be as easy as possible. Then you put everything together in something that can be released and installed in the environment and then be able to run it.
- Stateless Processes: You should not be introducing state into your services, applications should execute as a single, stateless process. The Twelve-factor processes are stateless and shore-nothing. The factor lies at the core of microservices architecture.
- Port Bindings: Your services should be visible to other via port bindings. If you built a service, make sure that other services can treat this as a resource if they wish.
- Concurrency: Break your app into much smaller pieces rather than trying to make your application larger (by running a single instances on most powerful machine available). Small defined apps allow scaling out as needed to handle varying loads. Each process should be individuall scaled, with factor 6 (Stateless), it is easy to scale the service.
- Disposability: Processes should be less time-consuming. Make sure you can run and stop fast. And that you can handle failure. Without this, automatic scaling and ease of deployment, development are being diminished. You can achieve this with containers.
- Dev-Prod Parity: Keep development, staging and production as similiar as possible so anyone can understand it and release it. Continuous deployment needs continuous integration based on matching environments to limit deviation and errors. This also implicitly encourages a DevOps culture where Software Development and Operations are unified. Containerization is a huge help here.
- Logs: Treat logs as event streams. Logging is important for debugging and checking up on general health of your application.
- Admin Processes: Run admin/manaagement tasks as one-off processes — tasks like database migration or executing one-off scripts in the environment. To avoid messing with database, use tooling to built alongside your app to go and check database.
