Adding Deployment Gating capability for GitLab for Jira Cloud app Integration
Proposal
Upon introducing #460663 (closed) Jira Service Management Integration through GitLab for Jira Cloud app. We have started receiving deployment events and started creating change requests using those.
For the 2nd step, our aim is to gate those change requests. Deployment gating lets you allow or prevent deployments at specific points in the change management process using a CI/CD tool that you’ve connected to Jira Service Management. When deployment gating is enabled, a change request is created in Jira Service Management. This change request is created by Jira automation. After the change request is approved, the deployment can be resumed.
Atlassian has different setup steps for connecting CI/CD tools to use the deployment gating feature. In order to use Deployment Gating with GitLab besides the basic configuration steps https://support.atlassian.com/jira-service-management-cloud/docs/set-up-deployment-gating/. We require users to create Service Accounts Token and save this in Change Management settings on the Atlassian side. Also, on the GitLab side, users need to enable this feature for either projects or groups and select which environments.
In order to make this integration bi-directional we need to receive inputs from users:
- Enable Deployment Gating: whether users want to enable/disable the bi-directional flow.
- Deployment Gating Environments: for users the filtering feature for specific environments(only possible values: production, staging, development, testing)
Development requires: after checking these configurations, initiate the deployment gating flow by adding a command inside the deployment event.
When the deployment that creates the change request has this initiate_deployment_gating command, and the user approves/rejects the Change request. This triggers our callback flow by using the deployment entity that we have received and the service account token we're planning to make a request to GitLab's Approve or reject a blocked deployment endpoint, and continue the blocked deployment.
Since this issue requires development for both products, it'd be more efficient if we could finalize the GitLab side first and deploy it behind FF(by enabling it at staging, we can easily do end-to-end test). Currently, I don't think documentation is needed, but when we finalize the development on both sides and all the required steps to configure have been finalized; I will also update the documentation on the GitLab side.
Example configuration screen at GitLab side:
