Group level integration with JIRA
Note: This has been promoted to an epic: &2137
Problem to solve
When an organization uses the Jira integration across hundreds of projects, even simple actions like rotating an auth token can be an extremely time consuming (and fragile) task. Because each integration has to be updated manually, a user must open the settings for every single one, and copy-paste the new information over-and-over. Additionally, each time a new project is created, a user needs to go configure that integration for the new project, requiring them to have access to those credentials.
This makes it extremely painful (or even untenable) for organizations with a large number of projects to use this integration. Anecdotally, a customer with approximately 200 GitLab projects must change their Jira credentials on a bi-weekly basis, for regulatory reasons. Every other week, an IT staff member must go through each project individually and paste in the new token, which takes about an hour of work, and is error-prone because it relies on repetitive human labor. Extending this example, for an organization with 2000 projects, this is effectively impossible.
Proposal
To solve for these problems, this issue proposes creating a Group-level integration with Jira. This integration will function in the same way that the current project integration works, but will allow that integration to be inherited by any projects within that group. This integration will be able to be set to be on
or off
by default, allowing group admins to choose which state makes the most sense for those child-projects.
It will also allow projects themselves to disable or override this integration, supplying alternate settings instead. This lets individual projects leverage alternate users/tokens, transitions, etc.
Intended Users
Short verison: Anyone currently managing a large number of projects that need to be integrated with Jira.
- Owners/administrators of GitLab projects, GitLab groups, GitLab installations, or Jira Workflows, or Jira Installations
- Working inside an organizations that have 100s (or even 1000s) of GitLab projects
- Where those projects each need to be integrated with Jira using the same settings
Jobs to be done
- Integrating Jira across a large number of projects in GitLab
- Overriding or disabling Jira integration for a single project
Workflows
Creating the group-level integration - Creation of integrations at the group level functions in the same way that creating integrations at the project level does today. Under Group -> Settings -> Integrations
, group owners can see a list of existing group-level integrations. They can edit the Jira
integration, and provide the settings (URL, username/email, password/token, transition IDs), as well as a setting for whether this integration should be enabled or disabled for projects by default. Once saved, all projects without a project-level integration in place will now reflect the default state of the group-level integration.
Setting up a new project - When creating a new project in a group with an existing group-level integration and that integration is set to be on-by-default, no action is needed. Under Project -> Settings -> Integrations -> Jira
, the page will reflect that the project is currently using the integration from the group level and have an option to disable this for this project, if necessary.
Changing a Jira settings across many projects - To change the integration settings in a group where group-level integration is enabled, the integration can be edited from Group -> Settings -> Integrations -> Jira
, and any changes made there will be reflected immediately in any child-projects that do not have a project-level integration in place.
Overriding a single project integration - If a project needs to have settings different from the ones provided in the group-level integration, they can be set in the same way project integrations are set today. Under Project -> Settings -> Integrations -> Jira
, project owners are able to override the group-level integration with project-specific settings, or disable the integration entirely. These settings will remain unique to the project, and changes to the group level integration will not be reflected in them.
Permissions and Security
Current permissions and security modeling around group owners being able to configure group settings should be followed. Currently, only group owners are able to edit group-level settings, and these settings are no different.
Documentation
- NEW Documentation will need to be added for the new group-level integration page
- EXISTING Documentation about the project-level integration should have a note added about the availability of group-level integration
Testing
What does success look like, and how can we measure that?
Success looks like a drop in the usage of per-project Jira integration and an uptick in group-level integrations that replace them. We should be tracking:
- Number of projects reporting an active project-level integration
- Number of groups reporting an active group-level integration
- Number of projects with no project-level integration that are using a group-level integration instead
- Number of projects with an active group-level integration that are overriding those settings with a project-level integration
What is the type of buyer?
References
- Ongoing Research Issue
- Opportunity Canvas (Mural)
- Salesforce Research Spreadsheet
- YCombinator Comment
Interested Customers
- https://gitlab.my.salesforce.com/0016100000zSnCQ
- https://gitlab.my.salesforce.com/0016100000W3BB4
- https://gitlab.my.salesforce.com/0016100000fDO7w
- https://gitlab.my.salesforce.com/0066100000RSffx?srPos=0&srKp=006
- https://gitlab.my.salesforce.com/0016100001PrOHM
- https://gitlab.my.salesforce.com/00161000002xBeQ