Question 104006 in Azure Question posted in
The official documentation to get you started can be found here.

Azure – What is the best approach for merging a feature branch into master when said feature branch is using a different build pipeline?

I am using Azure Devops in an IT environment with many different development teams and git repositories. Each development team owns one or more repositories. It’s my job to work on various application components contained in said repositories. Because I do not own those repositories, I should not make any changes in build/release pipelines, build policies etc, all by myself because that can impact other people’s work.

Now let’s say I have a feature branch named UpgradedFeature in the repository FeatureRepository, containing my changes. Said changes also introduce a breaking change in the build pipeline used for that repository for the master branch. Let’s say that pipeline is named MasterBuildPipeline.

So in order for my build based on the branch UpgradedFeature to succeed and not impact other people’s work, I make a clone of the MasterBuildPipeline, name it UpgradedFeatureBuildPipeline and configure the breaking changes. This new build pipeline is used exclusively by me for the UpgradedFeature branch only.

The build, now using the new UpgradedFeatureBuildPipeline pipeline succeeds and now I want to merge into master , so I make a pull request to merge the changes contained in UpgradedFeature into master. The master branch has a branch policy in place named MasterBranchPolicy like described on https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser. This branch policy contains the MasterBuildPipeline and prevents completion of that pull request when the build using that pipeline does not succeed.

So my problem is that my pull request triggers the MasterBranchPolicy containing the MasterBuildPipeline and not the UpgradedFeatureBuildPipeline containing the necessary breaking changes for the build to succeed. So the build fails and I cannot complete the pull request.

Of course I could edit the MasterBuildPipeline for a short time, introduce my breaking changes, run the build, then discard the breaking changes again. But there’s a chance I may impact other people’s work with that and somehow I have a feeling that’s not the right approach. I could also edit or disable the MasterBranchPolicy for a short time but again, I may impact other people’s work and I feel it’s not the right approach.

How should I do this?

Tags:

2

Answers


  1. 0

    Generally, workflow of DevOps Branching Strategy as follows

    1. Developer will create a feature or bugfix branch out of develop. One feature or bugfix branch usually stands for one JIRA bug or feature item. These branches are personal
    2. The changes will be pushed into the developer’s feature or bugfix branch.
    3. When the new feature or bugfix is complete.A developer will create a pull request. Pull requests open a code review phase.
    4. Once a pull request has been approved, the team lead or development team will move it into development.
    5. When the development branch has all the epics and bug fixes, i.e., the content planned for the next release, the development team or team lead will create a release branch. This initiates the release regression testing phase.At this stage, only bug fixes are accepted for release, and the workflow is similar to that of the development branch.
    6. Having a separate release branch will enable future development towards the next release in the development branch. Features for the next release are not included in this release. However, bug fixes for this release will be incorporated into the development of the next release as well.
    7. When release content meets the criteria, the release branch will be frozen, which means that it ends. Content from releases will be merged to master and tagged there. For the next release, a new release branch is created when needed.

    As per my experience, I would suggest creating branching policies like

    1. A pull request is requested to merge the develop, release, and master branches.
    2. Pull request approvers should be leads.
    3. All developers can create feature branches.
    4. All developers can push to hotfix and feature branches. Commit messages must include the JIRA issue id.
    Login or Signup to reply.
  2. 0

    So the build fails and I cannot complete the pull request.

    To complete the pull request even through the build fails, you could grant yourself Bypass permissions. Bypass permissions let you complete pull requests that don’t satisfy branch policies. You can grant bypass permissions to yourself then complete the pull request. Here is Bypass branch policies for reference.

    Please navigate to Project setting >> Repositories >> The repo >> Security >> user (yourself) >> Bypass policies when completing pull requests.

    enter image description here

    Then, you can Override branch policies and enable merge even the MasterBuildPipeline faild.

    enter image description here

    Please also note that use caution when granting the ability to bypass policies, especially at the repo and project levels. Policies are a cornerstone of secure and compliant source code management. In your scenario, it’s suggested to edit the MasterBuildPipeline and the MasterBranchPolicy or disable the MasterBranchPolicy as you mentioned.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search