search

WaelHamze / dyn365-ce-vsts-tasks

VSTS Extension for Dynamics 365 Customer Engagement
https://marketplace.visualstudio.com/items?itemName=WaelHamze.xrm-ci-framework-build-tasks
GNU General Public License v3.0
117 stars 56 forks source link

Solution Versioning and Pipeline Build Number #128

Open KimBon opened 4 years ago

KimBon commented 4 years ago

We are implementing Azure DevOps build and release automation on one of our D365CE projects, partly based on your tools. For version numbering, we are looking for a good way to track our deployments. We are thinking of extracting the version number from the solution.xml file via PowerShell script and pushing it as the Pipeline's Build Number. Not sure if this is a good practice or what could be the better alternative?

@WaelHamze Anyway, this could be a new task GetVersion (or an extension for GetSolution) and work the same way as MSCRM Set Version. If this is useful, in which project should this be added? Its a bit confusing in which project this should happen: xrm-ci-framework and dyn365-ce-vsts-tasks. What's the difference for these?

WaelHamze commented 4 years ago

@KimBon the GetSolution should get you the version if needed.

Most people do this the other way around actually, use the build number to set the solution version, so each time there is a new build, the solution version is updated.

KimBon commented 4 years ago

@WaelHamze Indeed we have been playing with GetSolution too.

In case of a build pipeline that exports and unpacks the solution, you could first set the version on the source environment based on the build number. However, for a actual release (eg sprint release), you might want to start from the checked in solution package? If you pack that solution, you want to rely on the solution version which is stated in the checked-in solution.xml?

We increment the revision part of the solution version during each nightly build. In a release build, we now set the build number manually during the merge of our develop into release branch. How would you approach this normally?

WaelHamze commented 4 years ago

@KimBon the versioning it a tricky one and it will depend on your process. Have you considered storing the version number in the library (variable group), You can then manage this independently from builds and environments and update manually if needed or during build.

KimBon commented 4 years ago

@WaelHamze we have tried several approaches:

  1. Variables in a variable group. The advantage is that you can set it for several pipelines. However the disadvantage is that you cannot set them on queue time. An alternative version of this was to update these variables via Powershell and prepare them for next run
  2. Variables on the pipeline, which can be set on queue time. These variables are used to set the version via SetVersion on the unpacked folder before Packing it to zip. I think in this option we have to leave the idea of having the right version in solution.xml but rely on DevOps instead?
  3. Read the version from solution.xml and update the BuildNumber of the pipeline with this. This would allow to have the right version from source control and apply it to DevOps. Its like the contrary of option 2.

I assume approach 2 is what you meant with your previous comment: "Most people do this the other way around actually, use the build number to set the solution version, so each time there is a new build, the solution version is updated."?

mathiasbl commented 4 years ago

I use GitVersion to semi-automate the build numbers.