Use and test a feature#

This is the description of the customer workflow from the Caascad point of view.

The documentation for customers is here.

The workflow consists in those main parts :

find the code
modify the code
check that the validation pipeline works
check that the deployment of the feature works
clean up / rollback the changes when needed.

Find the code#

The code is in a git repository. This is like a treasure hunt. The starting points are :

Find the gitlab repo#

The code of the feature is described in envs-ng/gitea_provision.cue as a provision_repositories.

Find a line like this :

{name: "monitoring-vm", organisation: "internal", owner: "caascad", git_corp_path: "caascad/applications/caascad-monitoring-vm", git_corp_tag: "v1.1.0", force_replace: true}

Identify the feature by its name. The git repo is in Gitlab at the path described in git_corp_path.

Note

This code is propagated with trackbone -c gitea_provision and the copy can be found in Gitea at https://git.<cloud zone>.caascad.com/internal/<feature name>. Extended rights are needed : use the login and password that can be found in Vault (in secrets/concourse-infra/global/gitea-caascad).

Find the configuration files#

Warning

In most cases, the file does not exist yet. This is normal : no one has used the feature yet.

When the configuration file exists, here is how to find it :

Open envs-ng/concourse_provisioning

Find a pipelines with the name of the feature. It may look like this :

pipelines: "monitoring-vm-client-\(zone.name)": #ConcoursePipeline & {
    parent_zone_name:          _target_zone
    team_name:                 "deploy"
    pipeline_name:             "monitoring-vm-client-" + zone.name
    pipeline_config_file:      "client-feature.yaml"
    feature_name:              "monitoring-vm"
    gitea_repo_configurations: "caascad-\(zone.name)/configurations.git"
}

Notice the gitea_repo_configurations above. This is the repo in Gitea. Example : https://git.<cloud zone>.caascad.com/caascad-<client zone>/configurations.
The configuration file is in this git repo (if it already exists). Its name is based on the feature_name parameter above with a .yaml extension. Example : monitoring-vm.yaml.

Tip

If the configuration file does not exist yet, you can create it. Follow the rule above to name the configuration file or it will be ignored.

Modify the code#

You can modify the code in the Gitlab repo found above. In most cases, it is either the ci/check.cue file or anything in the Helm chart.

Follow the usual steps in the Create a new feature documentation :

Propagate the git repo with gitea_provision
Propagate the Concourse pipeline if you changed a trigger. In other cases, the pipeline is already deployed and this step is useless.

Then :

Make a change in the configuration file in the customer git repo (Gitea) in a Pull Request (see below).
Validate the check pipeline (see below).
Deploy (if needed) (see below).

Change the customer configuration file#

Customer workflow#

The configuration file name and location is described above.

In the customer git repo (Gitea), create or modify that configuration file.

Tip

When the configuration file does not exist, you have to create it from scratch. You can find example in the configuration samples in https://git.<cloud zone>.caascad.com/caascad-samples/configurations. Find the configuration files in these dirs :

global/ : when the feature is deployed globally (on the Cloud zone). Example : Grafana dashboards.
environments/ : when the feature is deployed only on some customer environments like client clusters or client VMs. Example : monitoring of VM.

Create a new Pull Request with the changes.

This will launch a check job in the Concourse pipeline and a message will appear in the Pull Request in the Discussion. At the end of the check job, a report will be added in the Discussion.

Note

With Caascad user (with its extended rights), you can merge the Pull Request even if the check went wrong and the Merge button is red. The customer user will not be able to merge.

Troubleshooting#

When the message at start or at end of the job is missing or is not the expected one, you need to check the pipeline and the check job.

Concourse : https://ci-infra.<cloud zone>.caascad.com
team: deploy
name : described in envs-ng/concourse_provisioning as pipeline_name.
job name : verify-helm-values-<zone name>

Deploy the feature#

Customer workflow#

Warning

With Caascad user (with its extended rights), you can merge the Pull Request even if the check went wrong and the Merge button is red. Because the customer does not have such rights, you should not click on the Merge button when it is red !

Merge the Pull Request.

This will launch a deploy job in the Concourse pipeline and a message will appear in the Pull Request in the Discussion. At the end of the deploy job, a report will be added in the Discussion.

Troubleshooting#

When the message at start or at end of the job is missing or is not the expected one, you need to check the pipeline and the check job.

Concourse : https://ci-infra.<cloud zone>.caascad.com
team: deploy
name : described in envs-ng/concourse_provisioning as pipeline_name.
job name : deploy-helm-values-<zone name>

Clean up or Rollback#

When the feature was not deployed#

Checklist :

Remove the branch in the customer git repo (Gitea). This should automatically cancel the Pull Request.
Ensure the Pull Request is cancelled (or cancel it manually)
Either rollback or go to Production with the changes in the Caascad git repo (Gitlab).

When the feature was deployed#

Create a new Pull Request that will remove the configuration file in the customer git repo (Gitea).
Follow the customer workflow to deploy the removal of the feature (merge the Pull Request and check the Discussion in the Pull Request to ensure that everything went good)
Remove the branch in the customer git repo (Gitea) if it was not removed automatically at merge time.
Either rollback or go to Production with the changes in the Caascad git repo (Gitlab).