Skip to main content

One post tagged with "12 Factor App"

View All Tags

· 5 min read
Byju Luckose

In the rapidly evolving landscape of software development, the 12 Factor App methodology has emerged as a guiding framework for building scalable, resilient, and portable applications. Originally formulated by engineers at Heroku, these principles offer a blueprint for developing applications that excel in cloud environments. This blog post will delve into each of the 12 factors, providing real-world examples to illuminate their importance and application.

1. Codebase

  • Principle: One codebase tracked in version control, many deploys.
  • Example: A web application's code is stored in a Git repository. This single codebase is deployed to multiple environments (development, staging, production) without branching for specific environments, ensuring consistency across deployments.

Set Up CI/CD for Multiple Environments in GitLab

  1. Create a .gitlab-ci.yml file in the root of your repository.

  2. Define stages and jobs for each environment. Here's a simple example that defines jobs for deploying to development, staging, and production:

.gitlab-ci.yml

stages:
- deploy

deploy_to_development:
stage: deploy
script:
- echo "Deploying to development server"
only:
- master
environment:
name: development

deploy_to_staging:
stage: deploy
script:
- echo "Deploying to staging server"
only:
- tags
environment:
name: staging

deploy_to_production:
stage: deploy
script:
- echo "Deploying to production server"
only:
- tags
environment:
name: production

  1. Configure your deployment scripts appropriately under each job's script section. The above is a placeholder demonstrating where to put your deployment commands.

2. Dependencies

  • Principle: Explicitly declare and isolate dependencies.
  • Example: To demonstrate the principle of explicitly declaring and isolating dependencies in a Spring Boot application, we'll create a simple example that shows how to manage dependencies using Maven, which is a popular dependency management and build tool used in Java projects, including Spring Boot.

3. Config

  • Principle: Store configuration in the environment.
  • Example: An application stores API keys and database URIs in environment variables, rather than hard-coding them into the source code. This allows the application to be deployed in different environments without changes to the code.

4. Backing Services

  • Principle: Treat backing services as attached resources.
  • Example: An application uses a cloud database service. Switching from a local database to a cloud database doesn't require changes to the code; instead, it only requires updating the database's URL stored in an environment variable.

5. Build, Release, Run

  • Principle: Strictly separate build and run stages.
  • Example: A Continuous Integration/Continuous Deployment (CI/CD) pipeline compiles and builds the application (build stage), packages it with the necessary configuration for the environment (release stage), and then deploys this version to the server where it runs (run stage).

6. Processes

  • Principle: Execute the app as one or more stateless processes.
  • Example: A web application's instances handle requests independently without relying on in-memory state between requests. Session state is stored in a distributed cache or a session service.

7. Port Binding

  • Principle: Export services via port binding.
  • Example: An application is accessible over a network through a specific port without relying on a separate web server, making it easily deployable as a containerized service.

8. Concurrency

  • Principle: Scale out via the process model.
  • Example: An application handles increased load by running multiple instances (processes or containers), rather than relying on multi-threading within a single instance.

9. Disposability

  • Principle: Maximize robustness with fast startup and graceful shutdown.
  • Example: A microservice can quickly start up to handle requests and can also be stopped at any moment without affecting the overall system's integrity, facilitating elastic scaling and robust deployments.

10. Dev/Prod Parity

  • Principle: Keep development, staging, and production as similar as possible.
  • Example: An application is developed in a Docker container, ensuring that developers work in an environment identical to the production environment, minimizing "works on my machine" issues.

11. Logs

  • Principle: Treat logs as event streams.
  • Example: An application writes logs to stdout, and these logs are captured by the execution environment, aggregated, and stored in a centralized logging system for monitoring and analysis.

12. Admin Processes

  • Principle: Run admin/management tasks as one-off processes.
  • Example: Database migrations are executed as one-off processes that run in an environment identical to the application's runtime environment, ensuring consistency in administrative operations.

Conclusion

The 12 Factor App methodology provides a robust framework for building software that leverages the benefits of modern cloud platforms, ensuring applications are scalable, maintainable, and portable. By adhering to these principles, developers can create systems that are not only resilient in the face of change but also aligned with the best practices of software development in the cloud era. Whether you're building a small microservice or a large-scale application, the 12 factors serve as a valuable guide for achieving operational excellence.