Discovery: Change Management within Compliance Dashboard
Background
We've been iterating on the Compliance Dashboard and recently discovered that aggregating data as it relates to a group's projects would better help Cameron identify gaps.
Additionally, supplemental customer feedback and JTBD research has helped highlight the need to extend the insights of the Merge Request
view.
Problem to solve
Cameron has a number of questions to help understand how compliant projects are as they relate to Merge Requests. Using the Compliance Dashboard today, here's how well those questions can be answered.
Note: One existing constraint - only the latest merge request for each project is shown.
-
❌ Why did we make this change? -
✅ Who made the change? Exporting the commit history would show the author of commits -
✅ Who did the peer review? Partially, you can see who approved but may not know about all participants -
❌ Who released it to production? -
✅ Did the tests pass, what are the results, and what tests where run? Partially, we show the pipeline status -
❌ Did we do a performance test upfront and what where the results? -
❌ How did this affect the code quality? -
❌ Did all the security scans pass? -
❌ Were there changes to job and deployment config compared to previous change? -
❌ Did we deploy to staging before production? ❌ Did we test the rollback?❌ How did this change affect our metrics?
Much of this information is discoverable within GitLab, and aggregating it together would help Cameron execute the JTBD. Otherwise, Cameron must rely on pings or manually sifting through Merge Requests to discover what violations there might be.
Intended users
Job to be done (JTBD)
Remediate gaps to enforce compliance
When I am managing the compliance controls of applications, I want to ensure they meet all required criteria defined in the policies, so that it does not create problems for us during an audit.
Micro-job | Maturity |
---|---|
When I have complete visibility into adherence to policies, I want to know what is not compliant, so that I can address issues. |
Proposal
Answer the following questions above as data points in the current MR view (change management) of the Compliance Dashboard. We should modify the UI/structure to accommodate these insights.
The Merge Requests that will be displayed will only be the ones that we flag for review based on the following checks:
- Separation of duties
- Pipeline status
- Any others?
List | with drawer | full drawer |
---|---|---|
Further details
For each flagged change (MR):
Provide a view that enables Cameron to audit a project/team/organization's deployments so that they can know that what is currently being deployed into production and if there are changes that are not compliant.
Further iteration may include alerting on non-compliance.
Some of the above list is more of a "trace" or log for change management, which may not strictly be needed for a compliance report, but is useful and related. True compliance needs to actually evaluate the content. e.g. listing the authors of the git commits is valuable for noticing unusual authors; is there any way to automate that detection?
Permissions and Security
Customers have emphasized the importance of being able to also access this information through exportable data and API as well.
Documentation
-
What pages would need to be updated?
Testing
What does success look like, and how can we measure that?
Any qualitative feedback from customers using the Compliance Dashboard to audit their projects' changes to better inform direction
Adoption by GitLab to dogfood internally
What is the type of buyer?
-
TBD @mattgonzales
Unresolved Questions
-
How might we enable Cameron to follow different environments and know this progression of a Merge Request that has been flagged? -
Should this view focus on MRs or deployments? -
What other group(s) should be involved in the design and implementation? -
What are the specific JTBD for this view? -
What information do we want to present and in what format?