GitLab CI/CD
| Job |
Stage |
Description |
|---|
[metric-include]-unit-test |
test |
Runs unit tests |
lint |
test |
Runs golint |
push |
push |
Builds mage artifact using kaniko and pushes to Container Registry |
deploy |
deploy |
Invokes development or staging Spinnaker pipelines to deploy image artifacts |
release |
release |
Invokes production Spinnaker pipelines to deploy image artifacts |
build-docs |
docs |
Builds TechDocs artifact using mkdocs.yml |
publish-docs |
docs |
Pushes TechDocs site to Google Cloud Storage |
Helm Chart
The following is an outline of the Helm chart artifacts included in this repository.
├── chart
│ ├── templates
| | ├── _helpers.tpl
| | ├── configmap.yaml
| | ├── deployment.yaml
| | ├── hpa.yaml
| | ├── ingress.yaml
| | ├── pod-monitor.yaml
| | ├── postgres-deployment.yaml
| | ├── postgres-service.yaml
| | ├── secret.yaml
| | ├── service.yaml
│ ├── Chart.yaml
│ ├── values.yaml
├── values
| | ├── dev.yaml
Directories
-
chart/ - This directory contains subcharts, which are other Helm charts that your chart depends on. Subcharts allow you to package and manage complex applications as dependencies. Each subchart typically has its own directory structure.
-
chart/templates - This directory contains Kubernetes resource templates that Helm uses to generate configuration files when deploying your chart.
-
values/ - This directory contains configuration values for helm chart. The default dev.yaml and prod.yaml come with inline comments to define what each value controls.
Files
-
configmap.yaml - Stores configuration data in key-value pairs. This data can be mounted as volumes or environment variables in pods.
-
deployment.yaml - Defines how to create and manage pods running your application. It specifies container images, replicas, and pod rollout strategies.
-
hpa.yaml - Defines configuration for horizontal pod autoscaling
-
ingress.yaml - Defines rules for external access to your cluster, typically for HTTP and HTTPS traffic. It routes traffic to specific services based on hostname or path.
-
pod-monitor.yaml - If you're using Prometheus for monitoring, this resource configures which pods should be monitored and what metrics to collect.
-
secret.yaml - Similar to a ConfigMap but used for sensitive data like passwords and API keys. Secrets are base64-encoded and can be mounted in pods or used as environment variables.
-
service.yaml - Exposes your application to the network within the cluster. It can be used for load balancing and service discovery.
-
Chart.yaml - This file contains metadata about the Helm chart, including its name, version, and a description. It's essential for Helm to understand the chart and manage it properly.
-
dev.yaml - This file defines dev configuration values for your Helm chart.
Spinnaker
-
Configuration - This stage configures Triggers, Parameters and Notifications for the pipeline.
-
Bake(Manifest) - This stage builds a deployable artifact using a configured Helm Chart and values.yaml file
-
Deploy Namespace - This stage ensures that the Kubernetes namespace is correctly deployed.
-
Deploy (Manifest) - This stage deploys the previously baked artifact
-
Migration - This stage runs a manual check to determine whether to proceed with running database migrations.
-
Run Migrations - This stage runs database migrations
Deployment Clusters
By default, it is assumed at templating time that development deployments will be deployed to test-cluster-1 and
production releases will be deployed to platform-services
To change this to qm-services-dev and qm-us do the following:
- Edit
.spin/deploy-staging.json
- Update
variables.cluster from "qm-internal" to "qm-services-dev (legacy development)"
- Edit
.spin/release.json
- Update
variables.cluster from "qm-prod" to "qm-us (legacy production)"
Production
!!! warning
Replay server will need a cloudsql instances created in brave drive before production releases can be turned on.
By default replay-server does not release out to production environments.
Once replay server is ready for production and a production brave drive cloudsql instance is created, releases can be
enable from main by following the below.
Enable Production Deployments
!!! tip A lot of the production values in build/values/prod.yaml are best guesses when they were set up such as
cloudSqlInstance. Ensure these values are correct before enabling releases to minimize headaches.
- Edit
.spin/release.json
- Change
"disabled": true, to "disabled": false,
- Wait for the gitlab
update-spinnaker job to run for the change to take effect
