So .. here’s a short story for you in the hopes you don’t have to go through what we went through.. .
We like to think we’re well organized. We have many pipelines. A shitload of automated tests (+8500), including integration tests, upgrade tests, breaking change tests, copy document tests, .. you name it! And yes, also vNext tests.
But then “Intrastat happened”. I’m going to spare you the details, but “Intrastat” .. well .. has changed (and no, I’m not talking about the (de)localization plans .. yet). And we have been debating internally what the best approach would be for our customers, let alone for the partners of our product .. for the different affected countries involved. We wanted to make it as effortless as at all possible.
This debate took time. And Microsoft .. well .. they notified us by obsoleting the object “in time”. I’ll just take one object as an example…
There were multiple objects like this .. changed functionality .. and we had been working on a decent upgrade strategy from the moment these obsoletions started to fail our pipeline.
So – a few weeks ago, the plan was ready, and after implementation, we wanted to go live. Moving our new code in, and taking our old code out.
… taking our old code out ….
And our timing made that more difficult than expected.
See – about a month before a new big release, all new and updated AppSource apps need to comply with that new release to prepare for “smooth” transition. So, all of a sudden all our changes didn’t “just” have to comply with only v24, but also with v25.
And you can already guess: in v24, “Intrastat” was a whole different story than in v25. In v25, Microsoft deleted intrastat objects that we were still depending on in v24 (because of breaking changes).
Or in other words: we had to comply with v24 AND v25. Since v25 removed objects, we HAD to remove our extension-object as well. But if you do that, CodeCop AS0029 kicks in on v24:
error AS0029: The 'PageExtension' with ID 'xyz' and name 'Intrastat Jnl. Tem. Ext SMIFC' was found in the previous version, but is missing in the current extension. This will break dependent extensions.Same goes for Pages based on tables that don’t exist anymore!
So, we were in some kind of never ending loop we couldn’t get out of. Our pipelines failed both ways, .. and I didn’t see any way to handle this in AppSource.
Luckily, I was not alone. After posting on Yammer – sorry, “Viva Engage” – there was “Giuseppe Pintaudi” (thanks, man! 🙏) that pointed out that Microsoft confirmed to make the AppSourceCop “smarter” (red: fix the bug) in case of Obsoletions. I got other suggestions by first creating a v25-only version, and then a hotfix for v24. The latter would have been a massive job. So I went for Giuseppe’s solutions with crossed fingers and toes.. .
For my pipelines, it pretty much meant:
- ignore all codecops except the AppSourceCop (we wanted to only force the important AppSource stuff in this case)
- ignore AS0029 (because in our pipeline, that same fix from Microsoft was not there yet) with the ruleset
- make sure to comply with v25 (which is currently the Next version of BC) by compiling against those symbols. For app compilation, I didn’t really care much for v24 at this point, as I had to take the symbols with the removed objects into account.
- after that compilation (which by the way also tests for breaking changes against the previous AppSource version of the app), install on v24 environment, and run tests.
This way, I could build the app, and send it to AppSource Validation.
Success! Woohoo!!
Except .. Pages. We did have some pages that were based on a removed SourceTable. Pretty much the same problem as the PageExtensions – but while AppSource Validation was ignoring our PageExtensions, the same was NOT happening for Pages.
To solve this one, we tried to change the SourceTable to the “Integer” table and fix the errors accordingly – we just made sure to not make breaking changes (that the page still existed)!
Success once again!
HOWEVER – it was pointed out to me in the same Yammer thread – sorry, Viva Engage – that the AppSourceCop during AppSource validation was hotfixed, and now you can just remove pages that were based on removed objects! Didn’t try it, but it did work with PageExtensions, so it should work with pages as well!
Short story shorter:
From the moment we need to comply with vNextMajor – comply with it like there is no vCurrent. Sounds weird, but this mindset kind of solved all remaining problems in our validation (mainly on Pages and PageExtensions – the rest is “just” code 🤷♂️).
And yes, the story was indeed (much) longer. What we did to try to comply with both 😱 .. you don’t wanna know!
So – I hope this helps anyone struggling with the same (where I always feel like I’m the only one, it does seem an active topic on Yammer – sorry, Viva Engage).
Loading ...