A solution per app. Is that the strategy for ALM as surfaced on latest videos as best practise going forward?

[Gatwick]

Routing unpacked code through an Azure pipeline to move Dev>Test>Prod as shown on recent PowerCat videos is encouraging.

BUT the approach demonstrates one app and associated components in a solution. The implication is one solution per app.

This would get very complicated. 

Is/will it be possible to code DevOps pipeline logic to rebuild target solutions from a collection of newly modified and unchanged apps or similar? Replacing a complete target solution with all apps, even if only one app has minor changes is a big deal. 

It would be nice to know as we are planning to exploit the emerging CI/CD features.  Cheers, Richard  

[cchannon]

There is nothing about Dataverse solutions that prevents you from putting more than one app in a solution. What would make you think this is a constraint?

[Gatwick]

Hi CC, sure but my query is about a CI/CD world where we pipeline an App migration across environments. Manually we can tinker and patch but when you setup an automated solution there are choices to be made. If the master reference code/source of truth is to be checked into a Git repository, and you have apps A,B,C,D,E in a solution and only C is changed should A,B,D,E be refreshed from Git and ALM rechecked or the 'current' versions in the source Environment carried across (which defeats the Master concept). The PowerCat team example is 1:1 App/Solution. Cheers, Richard    

[cchannon]

Maybe I don't understand the issue here. You don't want one solution with all apps because then the solution version would increment every time any app updates and you pull a new solution. But you also don't want to have one solution per app because then you have a lot of solutions. 

So what is the end state you do envision?

[Gatwick]

Hi CC, PowerCat best practice seems to be envisioning a world where the master reference app is stored as code in a (Git) repository. This would be after code level inspection for performance, best practice, naming etc.

So this app-at-a-time approach would not ingest 5 apps in a solution for each to be inspected if only one has changed, doable but not practical. 

They maybe envisioning extract the one changed app then build the target solution from that and the other(s) stored in Git. That is the route of my enquiry where I posed the question does a DevOps CI/CD Pipeline have the capability to do a package logic?

Have you seen the YouTube, start at 20 minutes to get an idea if not. Cheers, Richard  https://youtu.be/xwCUJmrRI9E 

[cchannon]

Yes, DevOps can package and unpackage a solution file using Power Platform Build Tools for DevOps

[Gatwick]

Hi CC, sure, I get that DevOps can package and unpackage a solution file etc.

The matters are. 

1. The PowerCAT approach is one-app : one-solution.

2. The alternative is, say five-apps : one-solution

say. App A(v1) App B(v1), App C(v1), App D(v1), App E(v1) (All in UAT, all verified through DevOps to PROD) 

say  Change App C(v2) advised by owner

Do we take all A,B,C,D,E from UAT, verify only C, then push through DevOps to Prod without knowing if A,B,D,E changed?

OR

Take C from UAT, verify then load Prod solution with A,B,D,E from DevOps repository and C from UAT.

Cheers, Richard

[cchannon]

Yeah, I hear you. But I don't think those are your only options. There is a whole world of possibilities out there for solution management. In fact, on this very forum we've have comment threads in the past that go to 5, 6, 7 pages of discussion for even extremely niche areas of the topic ("What are Patches good for?", "Pros and Cons of unmanaged migration of individual developer customizations", etc.). Everyone has their own approach; to say that you have only these two choices because this "power cat" person says so is to lock yourself off from every other possibility out there.

For instance, what if you keep A, B, C, D, and E each in different repos, and push them entirely independently of one another? There is nothing to say you can't do that. Just because C is changing doesn't mean you need to push the others.

Or, what if only A and B are managed apps and C,D,E are unmanaged in a single unmanaged layer?

What if A, B, and C are managed each in an independent Dev environment, with D and E layered in a fourth, second-tier environment?

What if B and D share dependencies, or E and A share a form, and it needs to be updated?

There are a billion possible complications to solution stacks, and I promise you there are equally many possible solutions. You are asking us to answer, "Do I do A or do I do B?" and I am answering you, "you do whatever you need to do to make it work." If you have an environment with 5 stacked apps, you are in a pretty darn complex environment. For me to tell you to A or B would be silly because I don't know anything at all about that environment - you do.

Think about all your options, weigh your pros and cons, and absolutely comment back here if you want the community to help you weigh those pros and cons, but we can't prescribe an answer to something as potentially complex as a 5-app solution stack without knowing more than "it has 5 apps, and Power cat says X."

[Gatwick]

Hi CC, cheers, I think we're now on the same wave length!

With the PowerCAT team promoting 'ALM Best Practice' my initial query was 'are they really saying 1:1'

That is what their example is without any reservation. I'd wondered if they'd pick up on my question.

If I need any answer then it is for the question I originally posed:  

Can Azure DevOps pipelines be coded to merge code from different repositories when we're looking for an automated to app roll-out, driven by a Power App/Flow.  (And is this an ALM world they're anticipating?)

Yeah, maybe for a Azure DevOps community answer but a PowerCat observation would be nice.

Cheers, Richard

[cchannon · Accepted solution]

OK, then yes. Absolutely. It is very easy to have a devops pipeline work with multiple repos; even across multiple devops projects. You can readily create and delete files, folders, and entire repos as steps in the pipeline. So, (and I think this is the pattern you're getting at here) let's say you have repos A,B,C,D,E each representing an individual solution, representing an individual app. This is convenient for source management, but maybe less convenient for importing into an environment, SO, you could have one devops repo that grabs all (or a selected subset) of the content from these repos and builds an ad hoc solution, rolling in A alone, or A and B, or A,B,C,D,and E according to whatever your release needs are.

That said, the ALM Accelerator (part of the COE Starter Kit) is probably what you want to look at here. The COE has--among other things--a PowerApp that can look at a wide array of solutions you are pulling from a wide array of environments and gives you an easy click-to-promote kind of experience to go across your environments.

This won't address the objective of merging in DevOps, but it will introduce you to a huge array of DevOps actions you can take for managing solutions and the Canvas App might be a good alternative that makes managing 5 individual solutions a bit more tolerable.

Good luck!