search

ewingjm / development-hub

A continuous integration solution for Power Apps.
MIT License
36 stars 8 forks source link

Add a pull request for c# code changes #25

Closed markcunninghamuk closed 3 years ago

markcunninghamuk commented 4 years ago

It would be ideal to have a smart way to detect when code changes are made. For standard customisations e.g. dynamics customisations the current process is great. The challenge is when you have C# and typescript changes, do we want to automatically merge it to master?

ewingjm commented 4 years ago

Making use of the full pull request functionality in Azure DevOps would be difficult as we would need to block the Development Hub while a pull request was pending. This introduces a dependency from the merging process on the source control process and also means that we'd have to move unreviewed solution changes to the master instance in order to create the PR. In order to avoid this, we'd need one PR/commit for the source branch and one commit for the solution changes after the source branch had been approved. Having these two separate commits would be an issue as we'd then trigger any CI/CD processes twice.

The review of the source branch in the solution merge should form part of the solution merge review (as this is in effect the pull request replacement) but I appreciate this means we lose out on some of the Azure DevOps pull request functionality e.g. comment resolution and validation builds. I suspect the main issue is the lack of PR validation build.

My suggestion would be that we capture an Azure DevOps build definition ID on the solution records in a Validation Build field and have a Flow trigger this build for the source branch when a solution merge is created. The result of that build could then be fed back to the solution merge record.

ewingjm commented 4 years ago

It would be a lot more complicated, but there is probably a way that we could automatically create a PR when a solution merge is created with a source branch (allowing for line-by-line comments and other PR functionality) then trigger the merge process only after both the solution merge is approved and all policies are resolved on the pull request. The same PR could then be updated post-merge and completed automatically. A line could be added to the PR description requesting that it not be completed as it is an automated PR.

ewingjm commented 3 years ago

then trigger the merge process only after both the solution merge is approved and all policies are resolved on the pull request

@markcunninghamuk @ksulikow after discussing with Kriss, we might be able to go even further than this and offer the solution extract changes with the pull request. This would involve changing the process so that there is in effect no 'Approve' or 'Reject' at the point of creating the solution merge, but instead we do something like the following:

  1. Create a solution merge as 'Queued'
  2. Check if any solution merge is 'Creating pull request', 'Rejected' or 'Awaiting review' - if not, then continue to 3
  3. Update status to 'Creating pull request' (for example)
  4. Merge the development solution into the target environment
  5. Trigger a pipeline which creates a pull request with the extracted changes (along with any code changes if a source branch is supplied)
  6. On approval of the pull request, update the solution merge to 'Merged' OR on reject of the pull request, update the solution merge to 'Rejected'

This then results in the following scenarios:

Merged

If a solution merge was created after this one, start the merge process.

Rejected

The following buttons appear on the solution merge:

This would be a significant change to how the Development Hub has been envisaged to work up until now, but it would greatly improve the review/validation process and would highlight any unexpected changes that could come through with the development solution. The branch could also be used to deploy from in order to run automated tests. In addition, it would solve #31.