12-factor apps
#1. One codebase, 1 application
- Code base to be backed by a version control system such as Git, Subversion etc.,
- 1 code base = 1 app.
- Multiple apps sharing the same code is a violation of the 12-factor.
#2. Dependencies
Manage dependencies in your application manifest.
- Database, image processing libraries.
Characteristics:
- Dependencies are managed in the app manifests such as maven, gradle etc.,
What should you do or don’t do:
- Don’t use pre-installed softwares which will help in each environments. This will not automate the deployment.
- Don’t assume that the related dependencies will be in the environment where you deploy, you are responsible for wiring the dependencies.
#3. Externalize configuration
Application configuration referred here are values that are
- Credentials to access a database, or services such as S3.
- Environment specific properties
Motivation:
- Env properties stored in the code will be a violation since the code has to be redeployed whenever the properties changes.
- Also its not a good idea to store env values in the code.
#4. Backing services
Are services that the app talks to
Characteristics
- Services can be attached or detached whenever required.
Objective:
- A different SMTP server should be able to be configured without the need for code change.
#5. Build release run
Summary:
Build: Application code gets converted into an artifact such as a war file.
Release: the artifact now understands the environment - QA, Dev, Prod
Run: the app gets released in the specific environment.
Characteristics
- Strict separation between the build, release and run stages of the application.
- Every release must have a release id such as a timestamp or a incrementing number
- 1-click release - using CI/CD tool.
What should you do:
- Use a CI/CD tool, Jenkins, Concourse etc.,
Best Practices:
- Create smoke tests to ensure the app is running fine after deployment.
#6. Stateless Processes
Characteristics:
- The process running in the environment should be stateless.
- Should not share anything with other process.
- No sticky sessions
What should do or don’t do.
- Don’t store any data in a local file system.
- Sessions:
- Store your sessions if any in a distributed session storage db, such as Redis.
- No sticky sessions.
- Create stateless services.
#7. Port binding
The port binding for the application should be configurable and should not depend upon a particular infrastructure setup.
#8. Concurrency
#9. Disposability
Your application should work fine even though one or more of app instances die.
#10. Dev/Prod parity
Keep the developer environment as close as possible to the production environment.
#11. Logs
Ensure it is easy to view / debug logs even though there may be multiple instances of the services exists.
What should you do or don’t do:
- No System.out.printlns
- Write to log files on the web server using log4j like frameworks.
- Stream logs to an external server where it can be viewed easily. Send the logs to a centralized logging facility.
#12. Admin processes
Characteristics:
- Execute any migration scripts on deployment of a startup if any.
What should you do or don’t do:
- Store migration scripts in the repository.
