Internal Server Error using ALOpsExtensionAPI with 2 different sandbox on same tenant

[MortenRa]

Currently testing this with s2s and devport and seems to be working fine if only one sandbox on the same tenant, but if you try to publish through a release pipeline to a second or third sandbox on same tenant with the same package following error occurs.

2022-08-05T10:17:55.4868474Z *** Using Dev-Port deploy instead of API
2022-08-05T10:17:55.5063583Z Publishing to https://api.businesscentral.dynamics.com/v2.0/f7b6995f-da03-4722-93bd-cafb3db452b2/afrodite/dev/apps?SchemaUpdateMode=synchronize
2022-08-05T10:17:55.9821515Z ##[error]Status Code InternalServerError : Internal Server Error
Object reference not set to an instance of an object.

Not sure if this relates to the problem described in https://github.com/HodorNV/ALOps/issues/371 as the log or error does not indicate much info.

One problem that we got was an error like Cannot publish an extension with packageId: xyz, because the same package ID already exists

Maybe add the parameter -replacePackageId to be able to deploy to 2 sandbox on same tenant

If a Create a new release I´m able to publish to the second sandbox (then same error on the first sandbox occurs)

Furthere more I can not see an option for the schemaUpdateMode that would be nice to also control

[waldo1001]

If you look deeper in how BCCH does this - this is something we really don't like to see as a solution: it basically is going to edit some bytes in the app-file.

We'll look into it, bus we strongly advice to work with separate pipelines to make sure to always have a newly compiled app.

[MortenRa]

I'm all in for good ideas.. We run release pipeline trigger from latest build so it is newly compiled.

We publish to stage and uat environments and this setup is working on-prem but want to switch to partner sandbox which is a bit more strict.

Do you suggest to run a build for each staging/uat environment to have an artifact to trigger a release pipeline.

[waldo1001]

The problem is that Microsoft is using a hack (dev-port deploy) to be able to publish AppSource apps to a sandbox. This is just a back door, something to quickly make something working, and not an decent deploy through a dedicated API or something.

For that to work though, it needs yet another hack (the byte-change in the apps) to do this for multiple sandboxes on the same environments.

This is an insane approach, if you ask me - all of the complexity is hidden in BCCH, so the community is "happy" .. . Not me :(.

We're now considering the same kind of "byte-hack" like Freddy does - but only as part of the dev-port deploy, even without any parameter to keep it simple .. 🤔.

[waldo1001]

The byte-hack will be part of the next release (expected this week).

[MortenRa]

Tested and works fine, but I´m missing the SyncMode option to choose between

Right now when using dev mode it is default to synchronize, so need option to overrule this. and mention for @AdminHodor at BC Techdays 2022 (I will create a new issue for this)

[waldo1001]

New issue: #569

[waldo1001]

New parameter on ALopsExtensionAPI:

replacepackageid: False               # Force a new PackageID for each deployment. $(replacepackageid)

[PeterConijn]

Oh, thank heavens. I thought I was going insane(r) trying to find why this was happening. I agree that the Dev-method is far from optimal and Microsoft should look into methods to deploy AppSource apps to sandbox environments through a solid API.

In the meantime, the replacePackageID solves the problem for now enabling us to maintain a solid CI/CD flow.

Thanks!

[waldo1001]

Honestly, the "replacepackageid" is a hack that was introduced by Microsoft (BCCH). I would like MS to provide a more stable way to do these things to be honest 🤷‍♂️.