TL;DR
If you don't care to read below and just want to see some samples have a look at my open-source repo for Azure DevOps:
https://dev.azure.com/PowerPlatform-ALM/_git/PowerPlatform-ALM-Advanced
I have a few for GitHub Actions but checkout this one from melody-universe the other co-author of the ALM for Dataverse workshop. Poke around their other repos and you'll find some gems.
The long version
If you are here to learn about button smashing style automation you're in the wrong spot! Automation begins when your understanding of the fundamentals of Power Platform solutions has a solid foundation. So go read the documentation on the basics you need to know!
Overview of application lifecycle management with Microsoft Power Platform
I'm doing this in my spare time, so if there is enough interest I'm happy to share more or even do some videos. I and I believe Melody would agree that a solid foundation and healthy CI/CD is a requirement for long-term success.
Yes!!! Source control should be the source of truth for all of your code, customizations, and non-sensitive configuration data/metadata.
Your source control system should also be the hub through which all deployment occurs. Note that, source storage and artifact deployment need not occur from the same tool/service.
Doesn't matter to me (✿◕‿◕✿). Use what you are comfortable with and what will be easiest to maintain over time. My only preference here would be to use YAML so that your pipeline is configuration as code... You know, the whole source code as the source of truth things I just mentioned.
A good starting point are the official tools:
- Power Platform Build Tools (Azure DevOps) (open-source repository)
- Power Platform GitHub Actions (open-source repository)
Read the official document from the Azure DevOps Services team.
For GitHub Actions the official Power Platform tools have a task that supports creating a branch to start a Pull Request for a commit.
powerplatform-actions/branch-solution/action.yml
Hmm, yes and no, likely what you have today is a hot mess. I've done hundreds of projects and workshops over the last 5 years and generally speaking your starting point needs to be at the strategic level. I could do an entire write up on this as it is typically where I spent most of my time with teams at a whiteboard.
TL;DR: If your solutions are all in one development environment today and you don't have any real solution strategy/architecture... start with defining your application.
Why you ask? If you have multiple unmanaged solutions in one environment you actually have ONE solution. The reason for this is that unmanaged solutions do not lock in component references leading all components to be in an unmanaged state at the default/system solution level. Delete the unmanged solution and guess what??? All of the components are still there and you just lost the reference to them. Have fun poking through the default solution to find them all. Also, any other unmanaged solution with a reference to the component will be pointing to that same reference... modify that and you've now changed what might be expected behavior in another soltuion... See where I'm going with this?
A starting point - Often times I would do an exercise with teams making them define their business. e.g. What lines of business do you support? Admissions, Financial Aid? Do they share any process? Ok, let's draw that so we have a visual.
Like with most things preparation is 95% of the work. At least, that's my experience having recently prepped and paint all the rooms in my house that were wallpapered walls and ceiling...
That aside, with this visual in mind you can start to see solution boundaries. All I will say here is that to truly build isolated solutions they should generally appear as unmanaged in one development environment. Anywhere else, they should be imported as a managed soltuion to lock in the expected behaviour. You likely guessed by now, but this means if you have multiple solutions under development that have a well defined set of boundaries likely you will need more than one development environment to develop them.
- The vertical layers represent an import order we want to maintain to have deterministic deployments.
- In this visual we likely import plugins first along with CORE.
- After that admissions or financial aid can go in the initial order does not matter.
One benefit of this separation is that we can deploy updates to any of the solutions independently from the others.
Once you have this in mind you have a starting point. The workshop I co-authored on this topic goes much deeper and if workshops are your thing you should check it out.
https://community.dynamics.com/crm/b/crminthefield/posts/pfe-dynamics-365-service-offerings (ALM for Dataverse)
Have questions or want to learn about something specific? Leave a comment below.