Skip to content

GitOps workflow

To facilitate the use of some Caascad functionalities, fully automated GitOps workflows are implemented in customer administration environment.

The features available for use through these workflows are:

  • monitoring-vm: controls the deployment of all necessary configurations for virtual machines monitoring. More info for this customer environment specific feature here.
  • grafana-dashboards: controls the deployment of optional dashboards that are maintained by Caascad teams. More info for this global feature here.

Note

In this tutorial, please replace the following values:

  • ZONE_NAME with the name of the administrative zone (it starts with ocb-).
  • CUSTOMER_ENVIRONMENT with the name of the target customer environment.

Git repositories

To store features configurations files, several Git repositories are provided in your Git instance.

https://git.ZONE_NAME.caascad.com/caascad-samples/configurations

Contains samples files for all features available through GitOps workflow

https://git.ZONE_NAME.caascad.com/caascad-global/configurations

This repository stores the configurations of global features like grafana-dashboards

https://git.ZONE_NAME.caascad.com/caascad-CUSTOMER_ENVIRONMENT/configurations

These repositories (one for each CUSTOMER_ENVIRONMENT) store the configurations of customer environment specific features like monitoring-vm.

How to

For each global or customer environment specific feature, implemented GitOps workflow works in the same way. Here is the description of the steps to follow.

  • Create a new branch from master

    Note that in each repository master branch is protected by default, therefore only validated pull requests can be merged into master.

  • Create <feature_name>.yaml file

    Configuration files examples for each feature can be found in caascad-samples/configurations repository.

  • Commit in a new branch and create a new pull request to master branch

    An internal CI/CD pipeline will be triggered: it will check the configuration file and will add a comment in your pull request with the result of validation.

    If everything is correct, you will see these comments in the pull request (example with monitoring-vm feature):

    If validation fails, you will see these comments in the pull request:

    A pull request that was not validated by the CI is not mergeable.

    Tip

    If you don't see this message Started validation job for <feature_name>, amend your commit to update your pull request.

  • Make corrections if necessary and update your branch

  • Merge the pull request in master

    An internal CI/CD pipeline will be triggered: it deploys all necessary configurations and adds a comment in pull request with the result of deployment.

    If everything went well, you will see these comments in the pull request (example with monitoring-vm feature):

    If not, you will see these comments in the pull request:

    Tip

    If deployment fails, and the problem has been identified and fixed, you can make a commit without modification by doing git commit --allow-empty -m "Trigger job for <feature_name>.yaml" and redo the workflow (pull request, merge).