search

HodorNV / ALOps

ALOps
59 stars 24 forks source link

Suggestion ALOpsExtensionAPI: Skip if installed version is higher #593

Open DanielGoehler opened 1 year ago

DanielGoehler commented 1 year ago

Is your feature request related to a problem? Please describe. We just found a good model for us and our customer to release PTEs to the cloud customers with approval and scheduled release in the evening, e.g. at 18:00.

But sometimes there is more than one release held back by the schema, and Azure DevOps sometimes deploys the newest release after the older release, even if the Subsequent releases is set to Deploy the newest release and cancel the others.

Describe the solution you'd like ALOpsExtensionAPI currently skips uploading the app if it already exists at the environment. It would be nice if it also skips if a newer version is already present. (A warning would be good if that makes sense).

Currently you just get this error message and have to look in the environment to see what happened.

##[error]App publish failed. Check the 'Extension Deployment Status' page in the Business Central client.
##[error]App publish failed, aborting batch

Describe alternatives you've considered Contacting Azure DevOps, which has been difficult in the past.

Arthurvdv commented 1 year ago

Hopefully you don't mind that I want to suggest an extra scenario to this request.

The use case is when deploying to a Sandbox. In some exceptional situations a developer installs a PTE directly from VS Code and manually increases the version in the app.json to a (very high) number. When he leaves the PTE on the Sandbox I expect an error message from the ALOpsExtensionAPI step. There could be confusion about '..the latest version is installed..' because there's a good chance that's not the case.

The main difference here is that the extensions in published in Dev-scope and not as PTE or Global. So, when newer version is already present and published in Dev scope throw an error otherwise a warning like @DanielGoehler suggests.

DanielGoehler commented 1 year ago

@Arthurvdv Yes, I didn't thought of that and you are right.

(BTW: We use major and minor from the App.json, build no. is the pipeline build no. and revision is 0 (?.?.*.0). Devs can increase the revision, so the new version is always higher.)

waldo1001 commented 1 year ago

Makes sense!