0

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

Current status:

  • We have a solution (git repository) with a variety of different web projects
  • We have a MAIN branch and develop on separate feature branches
  • I have a CI build pipeline that starts automatically after each commit to a feature branch.
  • There are multiple release pipelines (for each project) that publish the output of the CI feature build pipeline to the DEV environment

Problem:

  • 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

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?

Shatterator
  • 13
  • 3
  • Is splitting the CI pipeline based on the changed projects an option? Create a CI pipeline per project or release pipeline? https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#paths – Alex AIT Sep 07 '22 at 12:56
  • @AlexAIT Hello and thank you for your answer. That would be an option, and if there isn't another, we'll probably have to do it that way too. What bothers me is that each CI build is just a copy that has a different branch/path filter. That also means that I have to make the structure of the branches more differentiated. Currently, the trigger fires whenever a commit occurs on a branch under feature/*. – Shatterator Sep 07 '22 at 14:10
  • You can also use path filters to filter by the actual changed files instead of the branch name, but you would probably need to use templates to avoid full copies for each CI build. – Alex AIT Sep 07 '22 at 14:41

1 Answers1

0

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.)

TTT
  • 22,611
  • 8
  • 63
  • 69
  • First of all thank you very much for your answer. Of course you are absolutely right and I meant after each push into the remote repository. We've just switched from TFVC to GIT and the terminology has changed a bit ; ) "...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 ..." This option also came to mind, but it seemed a bit complicated at first. I'll definitely take a look at how this could be implemented and whether this might be a viable solution – Shatterator Sep 08 '22 at 15:58
  • @Shatterator I think one the biggest sources of confusion when going from TFVC to Git is the word "checkout" means entirely different things. ;) – TTT Sep 08 '22 at 16:36