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

Getting version of Dynamics 365 solution (Get Version task) #79

Closed mpavlino closed 4 years ago

mpavlino commented 5 years ago

Hi @WaelHamze ,

It would be nice to get current version of dynamics 365 solution so that we could increment it automatically and possibly automate run of build procedure. My suggestion is to create Get Version task or something similar that would get current version of solution either form current crm instance or from xml.

Thank You Mirko

WaelHamze commented 5 years ago

@mpavlino wouldn't you want your build number and the solution version to match? Most users update the solution version based on the build number.

evilbaschdi commented 5 years ago

I currently read the Solution Version manually from Solution.xml in the "others" directory.

dominicusmento commented 5 years ago

@evilbaschdi how do you have your sandbox and prod instances in sync with versioning? If you read it from xml after extract+download solution than your version on sandbox stays lower than production version will be.. or do you increment both sandbox solution version live and production version directly in extracted xml?

evilbaschdi commented 5 years ago

We're right at the beginning of our release process so I did not make any thoughts about that. Our current process is Development => Test => Production. At the moment once the pipeline is triggered a version 1.0.0.2 gets exported from one system and imported into the next system. We currently only set git tags by the solution version.

But we maybe can increment versions by exporting the solution, reading the version, parse it to a type that can be incremented, add 1, repack the solution and re-import it to the CRM.

Or you update the "solution" entities attribute "version" with the incremented string.

dominicusmento commented 5 years ago

@evilbaschdi There is no need to re-import solution because you have set-version task in CI/CD. so you can just set it directly...

From my point, only solution which would be acceptable is to export and extract solution twice. First for reading the current version from dev instance... then use set-version to set it on same dev instance.. publish customizations.. then export and extract solution again for the main purpose.. git commit and publish to another environment..

What is missing in CI/CD is get-version task so we could read it directly from crm instance and skip some steps in my previous flow..

Another workaround which is not so great is to export all as it is and import to another environments too. After everything is finished, read current version and increment dev environment version by set-version for run of ci/cd... that way versions would also be aligned and also prepared for next build..

evilbaschdi commented 5 years ago

You're right, I forgot about that "Set version" task. A "get version" task would indeed be very nice to have.

dominicusmento commented 5 years ago

@mpavlino wouldn't you want your build number and the solution version to match? Most users update the solution version based on the build number.

@WaelHamze I think @mpavlino doesn't care about build number (because it sticks to that specific build and doesn't correlate to dev environment's solution version in any way).. The intention is to have 1 to 1 version number copy where it is ensured that version (patch) is incremented on every build to ensure that it is greater than the last one deployed.. for that we need an action which is capable of reading current solution version from specified environment.

WaelHamze commented 4 years ago

@mpavlino @tomidix There is a "MSCRM Get Solution" task that returns the version amongst other things as an output parameter