[Question] Process to detect breaking changes in VS Code (AppSourceCop) ?

[fvet]

Scenario As an AppSource developer I want to detect breaking change asap in the development process (= in VS Code, even before the pipeline or AppSource service warning me).

Currently we have an automated process in place (managed in Azure DevOps) that ensures the 'previous' app package is included as part of the repo whenever an (AppSource) release is made. In addition, the version in the appsourcecop.json is changed to the latest released version.

I'm aware that storing artifacts in your repo is not a best practice and ideally they are stored on a central storage. However, due to the lack of other out-of-the-box options in Azure DevOps / ALOps, combined without a lot of scripting in VS Code, this does the trick.

Whenever a developer needs to contribute to an app, the repo is cloned (including the previousapppackages). All that is required is a simple copy of the content to the .alpackages folder and the AppSourceCop is able to detect breaking changes in VS Code. Same applies when changing branches (e.g. to make a hotfix on a release branch ...)

---

I'm aware this is not a VS Code repo, but as it's closely related with working with AL-GO, I'd rather ask for a solution here

When moving to an AL-GO managed repository, what is the current solution for a developer to get started asap and making sure the AppSourceCop in VS Code is able to detect breaking changes?

Where to get the previous app file(s)? Are there any scripts available (same logic as in the github actions to discover the previous version while building an app) to perform a local download of the app(s) from the github repo / release artifacts?

[fvet]

A similar related topic might be 'where to get app dependencies from other partners' (in VS Code)?

As long as the other partner does not provide any feed or if we can't easily connect to this feed from within VS Code / Azure Devops to automatically download the needed apps, we decided to include the app file as part of the repo.

This allows both the build pipeline / ALOps to access the dependent app file to successfully build the app AND the developer to easily get started, as the app is immediately available when cloning the repo.

[jonaswre]

@fvet I'm certain there is currently no process like you have described.

We are currently not continually deploying our apps to app source. So for our setup the version we check for backwards compatibility is the latest GitHub Release. You could create a PowerShell script that downloads the latest release into your .alpackages.

And if you are continually deploying you will probably want to download the latest GitHub Package.

There are two good ways to handle dependencies to partner modules.

The first solution is to download the partners app file from there portal and host them somewhere where your runner can use a http get to download them. You can then provide a property "installApps": [url1,url2] in the Algo settings. Your workflows or when executing the LocalDevEnv Script will then download these files.

The second option is to upload these dependencies to your GitHub Packages, that's a bit more involved, because the current tooling cannot upload runtimes. You need to do that manually. But the advantage is the only thing you need to do in your apps is to specify the correct dependency in your app.json everything else is handled by AL-Go

[fvet]

@jonaswre Thx for your feedback.

Off-topic: Just for your information, we want to be part of the 90% of the partners that are looking for a 100% solution with AL-GO. Coming from a functioning Azure DevOps setup that took us quit some effort / budget / way too much custom scripting (on top of ALOps), we're currently considering a possible move towards github AL-GO as a fully configurable solution, not requiring any custom scripting.

We just don't have the resources to continuously invest in optimizing our development process by building one-off scripts and are looking towards MS / community initiatives to provide a smooth dev experience out-of-the-box. (that's at least our ultimate goal)

[jonaswre]

@fvet we are using AL-Go for almost a year and we have 35+ apps published to AppSource. I helped some customers to implement DevOps based custom tooling. And now I help some of them in moving to AL-Go. So I know some of the challenges partner face when migrating. And the most important one is if you have highly customized tooling in DevOps its either going to be expensive in time or/and money to get all to processes to AL-Go. Or you will need to change the way you develop your applications.

One of the great things about al-go is the community. But you can't expect the community to have a solution for every challenge you face. AL-Go is still in active development and hopefully will be forever.

And another is the integration hooks you can use to extends parts of AL-Go without sacrificing update ability.

[freddydk]

I guess this could be built into localDevEnv and cloudDevEnv. When setting up a development environment, also grab the latest release and place it in the right location enabling appsourcecop. The code for getting the latest release is fairly simple in GitHub:

$release = gh api "/repos/microsoft/bcsamples-bingmaps.pte/releases" | ConvertFrom-Json | Select-Object -First 1
$asset = gh api "/repos/microsoft/bcsamples-bingmaps.pte/releases/$($release.id)/assets" | ConvertFrom-Json | Where-Object { $_.Name -like 'bcsamples-bingmaps.pte-main-Apps-*.zip' }
Download-File -sourceUrl $asset.browser_download_url -destinationFile c:\temp\latestrelease.zip

This could obviously be made generic and added to the devenv commands.

[jonaswre]

For ensure updates are possible this would need to be added to the Core AL-Go Script or added as NewBCContainer or similar override.

[freddydk]

Yes - it is something that needs to be added to AL-Go

[dsaveyn]

As my colleague @fvet already pointed out, the AppSourceCop validation is really crucial in our development process. This because the release is often created by another developer than the one who did the original changes. To enable a smoother release process we'd like to catch breaking changes during the development itself.

Suggestion:

Why not create a new workflow that does the following:

• Triggered either manually or when releasing to AppSource
• Prepare a branch (based on the main branch) with the following changes:
  • Update the .appSourceCopPackages folder (configurable via a setting) with the latest released app
  • Update the AppSourceCop.json file with the version of the released app
• Create a Pull Request from the prepared branch

This is more or less the process we have in place for some of our existing appsource apps that are maintained using Azure Devops.

How do other partner's handle breaking changes? Circling back when a release to AppSource fails, seems like a real hassle. As far as I can see there's no AppSourceCop validation implemented in AL-GO at the moment (but I might be wrong).

[fvet]

Yes - it is something that needs to be added to AL-Go

@freddydk Any update on the above. Devs keep struggling with making local changes and have to wait for the Github actions results to return any warnings on breaking changes...

[freddydk]

Looking at this now. The way AL-Go works is to check the latest released version for breaking changes when building. When creating a release, the Create Release workflow also increments the version number and creates a PR with these changes.

What we could do would be to:

If an app folder includes an AppSourceCop.json file with a "baselinePackageCachePath" setting which is points to the github repo (f.ex. "./.appSourceCopPackages"), then the Create Release workflow should replace the latest .app files in that folder with the newly released version and update the version number in appSourceCop.json. (also ensure that the path is included in .gitignore as !./.appSourceCopPackages/*.app) - and include these changes in the PR it creates with the new version number.

This would ensure that this would work - both in a future codespaces scenario and a local development scenario.

So, all people would have to do is to create an AppSourceCop.json with a baselinePackageCachePath to make this work in existing repos - and new repositories could have this as default.

Would this solve the problem?

[freddydk]

This idea would require people to maintain an AppSourceCop.json file for every app really - which we really don't require today.

I think a better idea would be to have one setting (next to AppSourceCopMandatoryAffixes) identifying the path to the baselinepackagecachepath - and if that is set - all the stuff above is being updated - including AppSourceCop.json.

Setting could be like this:

  "appSourceCop": {
    "MandatoryAffixes": [
      "BIN"
    ],
    "baselinePackageCachePath": "./.appSourceCopPackages"
  }

[fvet]

Just catching up on this one.

App Files

As initially posted, maintaining a copy of the app files in the repo is probably not the better solution.

The way AL-Go works is to check the latest released version for breaking changes when building.

I would enfavour a solution in VS Code allowing use to perform the same in VS Code, either via the AL Compiler team using a commandlet 'AL: Download AppSourceCop Symbols' (similar to 'AL: Download Symbols') or via a standard AL-Go script 'Download AppSourceCop packages.ps1' (probably more likely to achieve)