Skip to content

ABANDONED - Add notification for release environment

Dat Tang requested to merge release-environment-send-noti into master

What does this MR do and why?

Describe in detail what your merge request does and why.

Close gitlab-com/gl-infra/delivery#19999 (closed)

Content

The code changes introduce a new feature to send Slack notifications for release environment deployments. These notifications provide information about the deployment status, environment name, and the version being deployed. Additionally, a new Rake task is added to allow triggering of these notifications from the GitLab CI pipeline.

Add notification for release environment

  • Add a new GitLab CI workflow only to send notification for release environment, to not mix up with other pipelines.
  • Add a new ReleaseTools::ReleaseEnvironment::Notifier as well as a corresponding Slack notifier class to send notification based on the release_environment's pipeline on gitlab.com.
  • Add rspec for new classes.

Note

Note on implementation decision

This implementation receive status as an input, to overcome the current limitation of release environment's pipeline. All environments are deployed in the same pipeline, so the logic of checking pipeline for the deployment status is not possible. I decided to choose this implementation to quickly have the notification available, so we can see the result as well as collect result data. I will create another issue to refactor the release environment's pipeline.

Detailed explanation of why we cannot use the status of the bridge pipeline as we use for deployer here:

The logic of the pipeline using deployer to deploy is:

With this logic, the notification job always runs after the trigger deployer pipeline job finished, and the status of the trigger deployer pipeline is exactly the status of the deployment to an environment (e.g. pre).

The logic of the release-environment pipeline:

  • trigger deploy pipeline --> All environments are deployed in one pipeline (e.g. 16.10, 16.9, and 16.8, example).
  • Thus, status of the pipeline doesn't reflex the status of each environment (e.g. the pipeline fails because the 16.8 deploy job fails, but the deploy jobs to 16.9 and 16.10 succeed).

Because of this, instead of using the smart logic of getting the status from the bridge pipeline, I use needs and when: on_failure between the deploy job and the notification job. This way, there is a 1:1 relation between the jobs of the same environment (e.g 16-10-stable:deploy, 16-10-stable:fail_notification and 16-10-stable:finish_notification, see the related MR for more information https://gitlab.com/gitlab-com/gl-infra/release-environments/-/merge_requests/191).

In fact, in case a new deployment is triggered for an environment (i.e. when someone merges an MR to a stable branch), the pipeline only deploys ONE environment corresponding to the stable branch (e.g.). Thus, one can argue that in most of the time, the pipeline status reflexes the environment's deploy status.

However, I decided to pick this lazy solution because:

  • It doesn't create more confusion (even though the confusion rarely happens)
  • Anyway, we want to refactor the pipeline in the future.

Author Check-list

  • Has documentation been updated?
Edited by Dat Tang

Merge request reports