Redesigned yml files with the idea of supporting multiple apps

[andreasblueher]

Hey Kamil,

first of all I want to thank you again for the work you put into piecing together the pipeline for building AL apps. I was tasked the exact same thing and after evaluating all the existing tutorials and blogs I decided to work with your solution as it seemed like the best fit.

There are 2 major areas where I tried to improve the files and I would like to use this pull request to discuss my changes and maybe find solutions to some of the remaining blanks in my code. Maybe we could also have a talk on the phone for some of the points, because sometimes text tends to be suboptimal if you're interested.

• current version does not allow to have more than one main app and one test app per repository. I know having multiple apps in one repository vs. including submodules for every each dependency tends to be a philosophical question, but my company decided on the latter.
• there has to be a settings.ps1 in every single app repository

I decided to move all configurations into the .vsts-ci.yml file, so users have one single point where they need to enter data regarding the pipeline. Using those values plus some other automatically calculated values I create a config.json which is saved in the working directory and used it throughout the process in the same fashion.

There are still a few design decisions to be made, but I wanted to created this first in case you completly disagree with my approach and this will stay a hard fork anyway.

• [x] I need a way to distinguish test from normal apps because I need a unique CodeunitId for each test app
• [ ] If a dependency is found, but the app.json can't be found an error should be thrown to the pipeline
• [ ] I want to add a way to be able to define specific apps within the repository to be build. Imagine a repo with 50 apps with dependencies all over the place. I don't want to rebuild each of them every time and rather those changed in a pull request
• [ ] What is a valid strategy for versioning multiple interdependent apps? Should all apps have the same version number?

ToDos

• [ ] Find out if app need to be updated to an app they depend on has changed/updated or if dependencies define a minimum version and multiple versions will be available at the same time in BC
• [ ] Create documentation on how to use Azure Key Vault and link it to the pipeline

If I have some more findings/ideas I'll update this post.

Cheers and I'm looking forward to hear your thoughts about the changes Andreas

[andreasblueher]

One thought I had today regarding the topic of testing. If every test app would have an install codeunit to add the codeunit to the central test tool page, one would need only to run the central test codeunit and would get the result for all codeunits which had been added before. Sounds like a idea?

[kine]

One thought I had today regarding the topic of testing. If every test app would have an install codeunit to add the codeunit to the central test tool page, one would need only to run the central test codeunit and would get the result for all codeunits which had been added before. Sounds like a idea?

I am using this already, it is why I have the code in the template in Codeunit 50000 (creating line in CAL Test Enabled Codeunit table) and when running tests, I am running codeunit 130402 which is part of the test suite and will run all tests inside the table CAL Test Enabled Codeunit. No need to change anything in the templates for this...

[kine]

Regarding the initial post:

I need a way to distinguish test from normal apps because I need a unique CodeunitId for each test app

No need for that, see previous post about the tests. Just run the stanard test CU and register the tests in install codeunit...

If a dependency is found, but the app.json can't be found an error should be thrown to the pipeline

I have not implemented yet the part which will automatically download missing dependency from package server (or do anything else by calling custom script, e.g. to download the app from file server)

I want to add a way to be able to define specific apps within the repository to be build. Imagine a repo with 50 apps with dependencies all over the place. I don't want to rebuild each of them every time and rather those changed in a pull request

I am against this. I think you need to compile all, to be sure, that you have not broken something by your change. Because you want to compile even all depending on the changed one, even when they were not changed.

What is a valid strategy for versioning multiple interdependent apps? Should all apps have the same version number?

Because the apps should be backward compatible, I think you can version them independently. The minimum version for the dependency you have in the app.json should be minimal version with which it is working. Which version will be used during build/release is another question. If all is backward compatible, you can use the current (as it is in the repo), or latest (when downloading it from package server), or exact if you want... but still, same or newer than defined in the app.json. And this is another why to build all in CI (taking current version in repository) and e.g. download current versions and deploy and test together in CD (downloading latest from package server, where you have latest "released" version).

[kine]

Regarding the versioning, I decided to version the apps only by major and minor version in app.json. The minor version is increased if schema is changed and upgrade code is needed (not when new field is created). Major version is increased if the changes are too big or there are breaking changes (if they will be allowed in Online on major version change, which I think are not yet) or there is big new feature introduced. Build no. and revision no. are generated during CI to make each build unique, even when same code is builded again.