Process

Deployment process

The deployment process follows a structured workflow to ensure efficient and controlled releases across multiple environments.

Deployment Config

The deployment-config repository acts as the central configuration store for deployment automation tools like Flux or ArgoCD, which synchronize Kubernetes clusters with Git-based configurations.

Key aspects:

• Contains rendered Kubernetes manifests, such as:
  • Deployments
  • Services
  • Jobs (batch operations)
  • HTTPRoutes
  • Ingress configurations
• Helm releases typically are not needed but are available if cluster-side support is available, allowing more advanced deployment definitions and configurations.
• Approval Process:
  • Pull Request (PR) policies ensure proper governance, especially for staging and production environments.
  • Automated deployment is enabled typicall for development and testing environments.
• Continuous Deployment (CD):
  • Supports fully automated deployments when new code is merged into a specific branch.
  • see CD details

Deployment Template

To simplify deployment definitions, the deployment-templates repository provides a set of reusable templates and configurations based on Helm.

This repository allows developers to:

• Define deployments easily with a structured configuration approach.
• Use templating mechanisms to generate Kubernetes manifests dynamically.
• Manage deployment consistency across environments.

Structure of a Deployment Template:

1. EIT config file

• config.yaml
• Core parameters like Helm chart name, Kubernetes namespace, and environment-specific configurations.

2. Helm values files:

• values.yaml
• Stores environment-specific values required for Helm charts.

3. Gateway configuration file:

• gw-config.yaml
• Defines API exposure, security settings, and routing rules.

Example Deployment:

Example blog posts service deployment

Approval Process:

• Mandatory PR approval policies are enforced for production and staging deployments.