Closed fvet closed 3 months ago
fvet
commented
2 years ago @waldo1001 Any input on the above? While reading https://en.beyond365.de/post/is-your-dependency-tree-getting-more-and-more-complex, it seems like Resolve-DependenciesFromAzureFeed can be (part of) the solution?
waldo1001
commented
2 years ago I have been thinking about this .. a lot .. but probably don't have the answer you desire.
First of all: at my company, we do it like you do: hardcoded referrals to templates. And that's actually quite conscious. The thing is: I want "extra" dependencies to be something very conscious: people need to think about it. And when a dependency is added, I want to know, either by a failing pipeline, or by a significant change (a change in a yaml stands out) during code review. So in my opinion, as you state it above, that is "best practice". Any kind of "auto resolve" can result in a lot of unmanaged and unintentional dependencies, which can cause problems in the long run.
That doesn't mean we can't look into concrete proposals.
We'll look into the "Resolve-DependenciesFromAzureFeed". If you have other proposals, I'm all ears!
While evaluating how we implemented ALOps for our product apps, I wonder if we could simplify the complexity of dealing with dependend apps. Some explanation.
For customers (PTE apps), we (mostly) have just one app (repo) that can depend on:
So far, for PTE apps, we can use one common pipeline / yaml template that does not need to know about dependencies, all dependend apps are part of the repo. We can easily apply the same pipeline on all these projects.
For our product (ISV apps), we have 40+ apps (each app is a separate repo) that can depend on:
Our own ISV apps : We have chosen NOT to maintain the dependend apps under a separate \.apps folder. Reason why are numerous, including the high number of pull requests / high volume of daily builds / frequent cross-app code changes / sequence of pull requests / pending PR's ... plus the complexity to add extra commits to all related repos in case a newer version of a dependend app would have been build (which happens a lot). For the ALOpsCompile step to succeed (either get the .app file from somewhere, or checkout the code to build ad hoc), we have created several custom yaml templates / scripts that :
Each app now has it's own CI pipeline, each containing their 'hardcoded' dependencies:
I'm still in favor of using the 'app.json' (that are strictly monitored by the code reviewers) instead as a basis to list / define the needed dependencies. The manifest defines WHICH dependencies are needed, and could share this with the pipeline / pass this as an array to download the missing apps in a next step.
The download dependend app step would then be a custom yaml template that could map which apps (based on name / app-id) to download from somewhere. I think this will still be a custom step, since we might opt to map an app-id to a pipeline / package feed / azure file / ... But being able to map in one central place (based on the missing dependencies detected by ALOps), would avoid the need to include the dependencies in each separate app CI pipeline.
PS: Looking at https://github.com/microsoft/AL-Go/blob/main/Scenarios/AppDependencies.md, a link to dependend apps is also part of the repo, although for a complex app structure, it would make things simpler if we could maintain a central catalog / registry on where to get apps from, based on the info from the app.json file.
I'm curious on how others are dealing with this complexity, and if ALOps could simplify some steps by using info from the apps manifest instead? (I remember this was one of the questions in the early beginning of ALOps, to move into this direction or not).