Design exploration for end-to-end traceability
Separate from requirements traceability, enterprises have a need to backtrace
Some companies operate in industries with stricter regulations, and have adopted policies that mandate traceability. From a customer:
Independence of Concerns. Regulated industries normally need to demonstrate “independence of concerns”, i.e. evidence that work done by one party is reviewed by an independent party. Currently there is no easy way in GitLab to ensure that patches or merge requests are approved by people who have not made the changes.
While we can rely on organizations to implement these concerns in their processes, we should be able to offer immutable evidence that these processes were adhered to.
In the future, we'd probably like to take this idea further and connect shipped code to specific releases and allow instances to tailor these approval and handoff processes, but we should start with what traceability looks like for MRs. In this issue, we'd like to explore what this might look like in an "enhanced" audit log view that allows a user to trace the full history of an MR - including all previous interactions.
- How can we show a full history of events for a merged MR?
- How can an auditor determine whether or not merged code meets policy?
Add an "Event History" feature to the admin panel.
- List MRs for the instance. Allow filtering.
- Allow a user to click into an MR and list a timeline for the MR, including:
- Issue interactions (assignments, comments, etc) and changes.
- Branch and commit history. Pipeline status for each run.
- MR conversation, assignees, approvers.
- Environments and deployments.
A user's able to trace major events for a merged MR in a single place in the UI, from idea to production.