Improvement for GitLab for Jira Integration(Possibility of adding a new Project level Integration Configuration specifically for Jira Service Management)
Release notes
Problem to solve
As a GitLab and Jira user, I would like to relate my GitLab projects with the Jira Services, so I can use this association for my deployment flow and incident flow.
Intended users
Software Developer, Application Ops, Application Development Director
User experience goal
The user should be able to display if they're connected to the GitLab for Jira Cloud app at group level and if they're; paste their service identifiers to a text input field on Project level Integration configuration, which they get from JSM(Jira Service Management), to associate their GitLab Projects to Jira Services.
Proposal
- All work is behind a feature flag
- GitLab for Jira Cloud app gets represented within the integrations list on the group level - this needs to be built.
- The enabled/disabled checkbox would be hidden (we do this with the GitLab for Slack app).
- When a group is linked to Jira, it enables the projects within that group to start working with the app too.
- We will allow people to to optionally fill the service ID at the group level, given that users can override the group-level value at the project level.
- It makes sense to show that the projects within the group have the same integration enabled. So GL for Jira Cloud gets represented within the integrations list on the project level. This needs to be built.
- The enabled/disabled checkbox would also be hidden. Instead would only be enabled/disabled through the group-level settings propagation. This should be explained shortly in UI.
- It would be possible to see filled in service ID field, if it was set up on the group level and it will be possible to (optionally) fill or change the service ID field. When filled in, this would enable the feature we're discussing (JSM connection). (This would be a little like how the Jira issue integration has a bunch of optional settings that enable extra features.)
- We'll add a data migration to backfill creating the integrations for groups/projects that are already linked in Jira.
- Disallow for GitLab for Jira Cloud app to be presented as an instance level integration.
- We can remove the feature flag
- Jira issue integration, currently displayed as Jira in the integrations list, should be renamed to Jira issue integration in the integrations list on all levels.
- Reshuffle documentation, so that we structure it like this:
* Jira issue integration, for all flavours of Jira, (represented in the integrations list at all levels with this name) * GitLab for Jira Cloud app integration, for Jira Cloud only (represented in the integrations list at group and project levels) * Enables the Jira development panel features * Optionally enables Jira Service Management feature * Jira DVCS connector, for Jira Server and Data Center (not represented in the integrations list, as this integration doesn't leave in the GL codebase) enables a subset of Jira development panel features
Further details
With this simple addition GitLab users start associating their projects with Jira services and enable features like
- https://support.atlassian.com/jira-service-management-cloud/docs/set-up-deployment-tracking/
- https://support.atlassian.com/jira-service-management-cloud/docs/what-is-incident-investigation/
Currently, Payload generated at deployment_entity.rb: { 'associations': [ 'issueKeys': [ 'ABC-123' ] ] }
Updated payload is going to be: { 'associations': [ 'issueKeys': [ 'ABC-123' ], 'serviceIdOrKeys': [ 'b:YXJpOmNsb3VkOmdyYXBoOjpzZXJ2aWNlLzIwM2VkMWE0LTE0MmEtNDE0Yy1hYjY4LTA1OGMzMDBkODAxMS9kMTAyMGIxZS01MjIwLTExZWUtYjY5YS0xMjhiMTk0MjQ=' # pasted service identifier from Project Level Integration Configuration ] ] }