gitazuredevopsazure-pipelines-release-pipelinebuild-pipeline

Azure DevOps multiple Release Pipelines for single CI Build Pipelie for multiple Feature Branches ; )


we've recently started using Azure DevOps and I'm having trouble setting up our release pipeline for the DEV environment.

Current status:

Problem:

Example:

Developer A is working on feature ChangeTireColor for project CarConfigurator

Developer B is working on ChangeFrameSize feature for BikeConfigurator project

A makes a commit --> CI build triggered

B makes a commit --> CI build triggered

A now starts the CarConfigurator release pipeline

Result:

Since the last commit was for project BikeConfigurator, the changes made by developer A are not in the output of the BuildPipeline and the release for CarConfigurator therefore corresponds to the old status.

Question:

How can I ensure that the CarConfigurator release pipeline always publishes the latest commit for a CarConfigurator feature? Is there an alternative to creating a DEV branch, always merging features into it and then make the release pipelines publish from DEV?


Solution

  • Your problem statement makes it clear:

    The output of the CI build pipeline always corresponds to the status of the feature branch that was last committed. The release pipelines therefore always publish the last feature branch commit

    It seems that each build appears to be blowing over the previous build. If you're going to do this, then you should only build from a shared branch, as you mentioned:

    creating a DEV branch, always merging features into it and then make the release pipelines publish from DEV

    Or, if you don't want to create a shared branch and wish to build each feature branch separately, then one solution is to store those build artifacts elsewhere so you can deploy them independently at a later time.

    Nitpicky Side Note: I'm guessing this statement is probably not quite true:

    I have a CI build pipeline that starts automatically after each commit to a feature branch.

    Commits would normally be made locally, so it's probably the case that the pipeline starts after each "push of new commits" on a feature branch. (This may seem obvious but I'd recommend using the exact language here to prevent any confusion, particularly for newer Git users.)