LikeLike

You can use the Set Version task in this extension. https://marketplace.visualstudio.com/items?itemName=WaelHamze.xrm-ci-framework-build-tasks here is an example using the PowerPlatform Build Tools in a YAML pipeline https://dev.azure.com/like10-demos/dynamics/_git/SampleSolution?path=/azure-pipelines-build-deploy.yml

LikeLike

LikeLiked by 1 person

LikeLike

No but the PowerShell script used above is located here: https://github.com/wesmacdonald/blog-code-snippets/tree/master/build/PowerShell

Wes

LikeLike

LikeLike

I’m working on a similar approach that works with DevOps TFVC for a client with a standing Development branch that auto builds pre-release versions similar to your setup. However, we’re reading the Version from the .csproj file. Our thinking is that the developer really needs to think about the “nature of the change” they are making.

Devopment branch builds auto append a pre-release tag like “-dev.1234” so that you don’t have to keep bumping the version in .csproj for every little commit. These are essentially “release candidate” builds. Once it’s signed off on, the Development branch would get merged to Release branch and that would trigger a Release build and drop the pre-release suffix “-dev.1234” resulting in 1.0.0, for example.

If we need to do a bug fix/hotfix, we can either make a change directly on Release branch or branch from the Release branch and create a Hotfix branch and merge back into Release for something like 1.0.1.

The reason we’re going with two different builds is so we can have Debug compilation of -dev pre-packages and Release compilation of production builds (i.e. 1.0.0).

We’ve got debugging working with debug versions and source symbols, but still trying to get debugging to work with release versions and source symbols.

I really like your release promotion strategy as it “feels” better than running a separate build from a separate branch. If I could iron out the bug fix/hotfix strategy and debugging of production nuget packages, I think we could simplify with just one build and a multi-phase release/deployment like yours.

Curious to get your thoughts.

LikeLike

Hey Adam,

Great question, obviously we’d have to allow the editing of Major & Minor variables including specifying a branch or tag so the correct code gets built and tagged so it is published to the proper feed.

I think that would give you what you need.

Wes

LikeLike

Great stuff here. This looks like a great pipeline setup for planned work. My question is let’s say you have released 1.0.0 through this setup with alpha, beta, release versions of the package making it release.

Now, you have started on version 2.0.0 of the package. How do you handle a bug fix to the 1.0.0 version if you need to get that out before 2.0.0 is released?

Thanks in advance!

Adam

LikeLike

Great stuff here. This looks like a great pipeline setup for planned work. My question is let’s say you have released 1.0.0 through this setup with alpha, beta, release versions of the package making it release.

Now, you have started on version 2.0.0 of the package. How do you handle a bug fix to the 1.0.0 version if you need to get that out before 2.0.0 is released?

Thanks in advance!

Adam

LikeLike