Use case 12

  • Author: Jarno Huusko
  • Date / Version: 20/02/2024 / 1.0

User roles

  1. Ops/Sec (Actor1): Responsible for setting up and maintaining the CI/CD pipeline, automating the build and deployment processes.
  2. Dev (Actor2): Commits code changes to the repository, triggering the automated pipeline.
  3. Ops (Actor3): Monitors the deployment process and environment stability post-deployment.

Prerequisites / Conditions

  1. The project codebases for both frontend and backend are stored in GitLab repositories.
  2. Docker and GitLab CI/CD are configured and available for use in the project environment.

Use Case Diagram

uml diagram

Description of use case -eg. Modify existing request

  1. Pipeline Configuration: The Platform Engineer sets up the GitLab CI/CD pipeline, defining the steps for building the Docker images, running tests, and specifying conditions for deployment to staging or production.
  2. Code Commit: Developers commit code changes to the GitLab repository, which automatically triggers the CI/CD pipeline.
  3. Build Process: The pipeline executes predefined scripts to build Docker images for the frontend and backend, incorporating the latest code changes.
  4. Registry Upload: Successfully built Docker images are uploaded to the GitLab container registry, tagged with the commit identifier or build number.
  5. Automated Deployment: Depending on the pipeline configuration, Docker images are deployed to either the staging environment for further testing or directly to production, ensuring a seamless release process.
  6. Monitoring: Post-deployment, the Operations Team monitors the application performance and stability, addressing any issues that arise from the new deployment.

Exceptions

  • E1: If the build or deployment fails, the pipeline is configured to halt progress and notify the responsible parties (e.g., Platform Engineer, Developer) to investigate and resolve the issue.

  • E2: If critical bugs are identified in staging, the deployment to production is automatically rolled back or halted until the issues are resolved.

Result

  • The automated pipeline is triggered with every code commit or as configured within the project's CI/CD settings, ensuring continuous integration and delivery.

Use frequency

  • This use case is executed monthly as part of regular security maintenance, or more frequently if critical vulnerabilities are discovered.

Additional information

  • Documentation should include detailed pipeline configurations, troubleshooting guides, and rollback procedures for managing deployment issues.

Sources

  • The development and implementation of the automated pipeline are based on best practices in CI/CD methodologies, utilizing GitLab CI/CD and Docker technologies.