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

Import Solution Version Number Check #116

Open sannicolao opened 5 years ago

sannicolao commented 5 years ago

When im importing a Solution which has a lower version number then the solution which is currently installed, the solution with the lower version number will import. The check is only it both version have the equal version numbers. if not, the solution from the git will installed.

How can i prevent the installation of a solution with a lower version number? thx.

RonnyVDS commented 5 years ago

If you use azure pipelines you can use condition i think. https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml

sannicolao commented 5 years ago

I use an azure release pipelines to import my solution and in a release pipeline im not able to edit the yaml manually. So i cannot use those conditions.

WaelHamze commented 4 years ago

@sannicolao

The task doesn't prevent this in case you really wanted to install a previous version.

The questions is what is your use case and why are you triggering a pipeline with an older version if you don't want it?

sannicolao commented 4 years ago

@WaelHamze : im working in big teams, which are working on the same organisation. in this situation you will have the situation, that one guy didn't refresh his repository and the other guy did some customisation on the org. In case of this situation, the guy with the repo, which isnt refreshed, will push his changes, an build and a release will run automatically. If I would be able to prevent the import of old solutions, i would be able to prevent that this guy will overwrite the customisations of the other guy :)

i know, its a misstake of someone, but that happens in our teams some times, after we use your tools :)

sannicolao commented 4 years ago

@WaelHamze : I have another use case.

If you have two organisations. (one for dev, one for cust) and you have CI / CD. We want, if someone (a dev guy) added code, that the code will be deployed to the cust organisation.

for this reason we made a build an a releasepipeline.

If the cust guy did some cust on his organisation and will update the version number (he didnt exported his stuff already), and the dev guy pusched new changes in the master branch (which is the trigger for build), he will overwrite the customisations of the cust guy, cause in the releasepipeline there is the "old" artefact linked from the cust guy.