Rollout Feature for everyone as soon as it's ready
Beta Groups/Projects:
gitlab-org/gitlab project
gitlab-org/gitlab-com groups
...
Expectations
What are we expecting to happen?
This Feature Flag toggles the usage of the GrahpQl mutation for creating Jira Issues for vulnerability and the usage of REST Endpoint to create such issues.
What might happen if this goes wrong?
What can we monitor to detect problems with this?
Rollout Timeline
Initial Rollout
Preparation Phase
Enable on staging (/chatops run feature set feature_name true --staging)
Test on staging
Ensure that documentation has been updated (More info)
Announce on the issue an estimated time this will be enabled on GitLab.com
Check if the feature flag change needs to be accompagnied with a
change management
issue. Cross
link the issue here if it does.
Partial Rollout Phase
Enable on GitLab.com for individual groups/projects listed above and verify behaviour (/chatops run feature set --project=gitlab-org/gitlab feature_name true)
Verify behaviour (See Beta Groups) and add details with screenshots as a comment on this issue
If it is possible to perform an incremental rollout, this should be preferred. Proposed increments are: 10%, 50%, 100%. Proposed minimum time between increments is 15 minutes.
When setting percentages, make sure that the feature works correctly between feature checks. See #327117 (closed) for more information
For actor-based rollout: /chatops run feature set feature_name 10 --actors
For time-based rollout: /chatops run feature set feature_name 10
Make the feature flag enabled by default i.e. Change default_enabled to true
This is an important phase, that should be either done in the next Milestone or as soon as possible. For the cleanup phase, please follow our documentation on how to clean up the feature flag.
Announce on the issue that the flag has been enabled
Remove :feature_name feature flag
Remove all references to the feature flag from the codebase
Remove the YAML definitions for the feature from the repository
Create a Changelog Entry
Clean up the feature flag from all environments by running this chatops command in #production channel /chatops run feature delete some_feature.
Final Step
Close this rollout issue for the feature flag after the feature flag is removed from the codebase.
Rollback Steps
This feature can be disabled by running the following Chatops command:
/chatops run feature set --project=gitlab-org/gitlab feature_name false
@dpisek - I closed #323306 (closed) but am realizing that may have happened prematurely. This feature flag is still only enabled on staging & I'm unclear on what remaining work needs to be done to roll out this feature on production. Can you please take a look at this & refresh me on where we're at with this issue (񎻪 (closed))?
@lkerr@dpisek Should this go in the current milestone? If not, let's put it in an appropriate one or %Backlog so the bot stops yelling about it not having one
I just had a quick look and found an issue with the feature: The button shows even if Jira-issues are not enabled. I've created a separate issue to capture this and added it as a blocker: #337058 (closed)
I think this is also blocked by the rest of the GraphQL migration work
Currently the only place where we use the GraphQL API to create a Jira-issue is the vulnerability details page.
On the pipeline modal it still uses the link-based approach. If we want to keep it consistent we will either have to add this to the legacy modal or wait until the new modal has been deployed.
I've added the story that deals with the modal's migration to GraphQL as a blocker.
@matt_wilson - I agree that this work (along with both blocking issues) fall under the Q3 directive of addressing performance concerns & tech debt. I'm putting this issue in %14.4 & #337058 (closed) in %14.3. This will hopefully allow enough time to complete &4969 (closed) (contingent on BE dependencies).
Thanks @lkerr! I added this and #337058 (closed) to our planning priorities issue in the performance section at the top. I wasn't completely sure I got the right order/position for these so feel free to move around accordingly.
I do not believe this issue requires any further workflowrefinement. I'm adding a weight of 1 based on other feature flag rollout issue weights & setting it to workflowblocked.
@dpisek - I'm admittedly confused about the dependencies of rolling out this feature flag. Based on #300755 (closed) being a blocker, do we need to roll out the pipeline_security_dashboard_graphql feature flag before this createVulnerabilityJiraIssueViaGraphql feature flag can be rolled out?
That is a good question @lkerr , I had to dig around a bit to get a complete picture too!
So here is my summary:
We are using the "Create Jira issue" button in 4 places: MR-widget modal, pipeline modal, pipeline listing, and the vulnerability details page.
Currently the only place where we switched over to the GraphQL-version of the button (behind this issues' feature flag) is the vulnerability details page
The UX difference between the link-based and GraphQL approach is quite noticable - opening of a new page, etc. vs an async and behind-the-scenes operation
Only Jira issues that got created via GraphQL are currently counted on the vulnerability listing
Given the last two points I think we should not enable / remove this feature flag unless all places are using the GraphQL-buttons
MR-widget modal
Pipeline modal
Pipeline listing
Vulnerability Details
Vulnerability Report
While we are not really blocked by any other feature flag, I think the work we are doing as part of the pipeline's GraphQL migration would cover us for the pipeline's modal and the listing's action button.
If we don't want to wait for those pieces (especially since they have some backend dependencies as blockers), we could still go ahead and add it to the current modal, etc. - Famous last words, but I don't think it would be a huge effort.
Only Jira issues that got created via GraphQL are currently counted on the vulnerability listing
Follow-up question(s):
Does this mismatch only apply to the issue count, or does this impact our ability to display the issue links in general?
Given that we've never created Jira issues via GraphQL in production (with the exception of cases behind this feature flag), did the Jira issue links ever appear on the Vulnerability Report or did we introduce a new regression along the way?
Does this mismatch only apply to the issue count, or does this impact our ability to display the issue links in general?
Yes, good point - this applies to both the count and the list of Jira issues that are related to a vulnerability (which get displayed in the tooltip for the count-badge)
Given that we've never created Jira issues via GraphQL in production (with the exception of cases behind this feature flag), did the Jira issue links ever appear on the Vulnerability Report or did we introduce a new regression along the way?
They haven't appeared on production yet. I did some more digging and found an old issue that covers this:
#321938 (comment 517532586)
@lorenzvanherwaarden@subashis this pops in our "feature flags needing attention" report, as you can see above . From my understanding, this can be tested and enabled once all functionality is using GraphQL, which should be after we enable the new pipeline security page. Could you review and see if that is accurate?
@nmccorrison The feature flag is only used on the vulnerability details page to render a different "Create jira issue" button (using the graphql mutation instead of an external url). I don't believe we need to wait on enabling the new pipeline security page. I see that the same mutation vulnerabilityExternalIssueLinkCreate is already used on the new finding modal which is globally enabled. So I think we're safe here.
This is how it looks; it may be good to double-check if this is still what we want? The button is in the success variant instead of the confirm variant. /cc @beckalippert
ff disabled:
ff enabled:
I haven't tested whether it works because I don't have a jira integration running on my GDK at the moment, but I can definitely do that later.
Interesting. Thanks @lorenzvanherwaarden. It's strange that the style is different. Probably because it wasn't covered when we updated to the new/blue style guide. Let's see what @beckalippert says and we can probably schedule into 16.11.
@nmccorrison I'll update the button when the ff is enabled to have the blue confirm variant first. I'll try to test whether it works (with Jira instance connected) and should we then just do a feature flag rollout?