search

forcedotcom / devops-center-feedback

61 stars 2 forks source link

Reject Pull Request Automation #47

Open anspaujd opened 3 years ago

anspaujd commented 3 years ago

Is your feature request related to a problem? Please describe. When a pull request is rejected or 'not approved' the work item stays in an "In Review" stage and is locked to the current Pull Request.

Describe the solution you'd like It would be helpful to put the work item back to an "In Progress" status and bring the Pull Request review comments into the DevOps Center screen allowing the user to make additional changes and resubmit for new review when ready.

Additional context

kfidelak94 commented 3 years ago

@anspaujd I'm not sure if you're aware, but you can "unapprove" the Work Item by flipping the toggle back to the off position in DevOps Center. This will put it back into the "In Progress" state. Note that this is only able to be done before the Work Item has been promoted.

Your suggestion to bring the review comments from the Pull Request back into DevOps Center is something we've talked about. At this point we've taken an approach of trying to lean on the source control system for this capability vs. trying to build/replicate the commenting/collaboration capability in DevOps Center. Would the comments provide value to you, even if you could not actually edit/add to the conversation from DevOps Center? Or would that potentially be more frustrating?

anspaujd commented 3 years ago

@kfidelak94 - I have several customers who have "Release Managers" who work solely in the source control as the main hub. The current workflow would break their governance / release processes since the rejection and feedback should originate from the source control UI. There are a couple other systems I have seen tied to this such as JIRA, GitLabs and even MetaCI which are where the non-technical resources work and are dependent.

Basically, the workflow that I am referencing would be:

  1. User submits work for approval and PR is created in Github
  2. Release Manger / Code Review Teams review the PR in Github or local tooling of choice
    • If approved, PR is closed and merged into next branch
    • If rejected, the PR is rejected and feedback is added to PR. This would then post the feedback to the DevOps Commit feed for communication to the user who submitted on what / why it was rejected.

The main issue that I am seeing with the current workflow is that it requires the Reviewer to go into DevOps Center and manually flip the toggle on each work item when the PR action could do this for them or have the non-technical users learn and monitor for something in the source control. I have customers who have several hundred PRs weekly so this manual step would be extremely cumbersome for them when the action has already been completed in the source control.

This also creates a dependency on all users knowing how to use the source control system when DevOps Center is positioned to reduce this dependency. Several customers who I have discussed the tool with love the fact that as long as their users have a Github user they can use DevOps Center. This workflow requires them to either add manual work to the Release team for each Work Item or the non-technical users to monitor and leverage the source control tools.

anspaujd commented 3 years ago

@kfidelak94 - Another thought on this is that there is no feedback loop in the DevOps Center other than another branch commit. When the Reviewers / Release Manager want to reject it, there is no means (that I see) to provide the feedback on the work item without creating another commit.

The challenge with this commit is if any automations are in play on the commit event in the source control or secondary tools via webhook then the work is re-initiated unnecessarily. If the comments / feedback loop from the source control can post the feedback direct to the thread in DevOps Center it would allow the users to see the notice, execute requested changes and resubmit for approval.

kfidelak94 commented 3 years ago

Thanks for this feedback @anspaujd ! For this pilot, the flow is (intentionally) intended to be limited to a DevOps Center-centric workflow. For the beta, we will be adding support for workflows where actions are taken outside of DevOps Center, including either directly in GitHub (ie, PR approval, merge, etc), or via the CLI or automated processes. We are planning to support more of a "two-directional" flow where DevOps Center can react to changes that are initiated outside of it. We're working through these flows right now. I may set up some time with you to talk you through our thoughts and get your feedback.

anspaujd commented 3 years ago

@kfidelak94 - Happy to do so since we are also using MetaCI & CCI internally to do automated builds based on commits. We would love to talk through the use case and flows that we are seeing "missing" in the current pilot and help shape the tool for the future.