Remember the ALM Accelerator by the PowerCAT team? It’s a phenomenal ALM solution that allows you to deploy solutions across environments using a Canvas app. That’s just the front end though. Behind the scenes are complex YAML scripts that use Power Platform Build Tools within Azure DevOps to move your solutions around. But more related to today’s post, the ALM Accelerator also unpacks your solution into an Azure DevOps Repo ensuring you have structured source control alongside your deployments. Why am I bringing this up again? Well, I’ve recently been playing around with the Power Platform Git Source Control feature and am thoroughly enjoying it.
Why Git Matters
Gits history in the context of Power Platform has always had a pro-code connotation. Aside from tools like the ALM accelerator, Git needed to be done through YAML and Build Tools within Azure DevOps, or pac CLI on your local device. The benefits of Git vary, however some key benefits I’ve found useful are:
- Collaboration: Having multiple developers work concurrently without overwriting each other’s changes.
- ALM: Simplified low-code ALM practices with version control, change tracking, and more.
- Governance: Accountability and reliability become more robust and audit trails and compliance are manageable with integrated source control.
Power Platform Git Source Control
This new source control feature now allows low-code developers to connect solutions and environments to Azure DevOps repositories to manage source control. Similar to Build Tools and pac CLI, the Git Source Control feature unpacks your solution into the target repository.
By implementing this type of source control to your solutions and environments, you are able to track solution changes, manage collaboration, and create restore points as needed. If you have ever used pac CLI or Build Tools to unpack a solution, you’ll notice it unpacks your solution zip file into a variety of files and folders. Most of these files are .xml, .yml and .json. All these folders and files are what make up your solution. A great example would be the recent View Code feature in a canvas app. This allows you to view the YAML code that makes up a control and its function. Unpacking a solution results in this YAML being stored in .pa.yaml files in the target repository.
Having this in mind now, you can start to see how certain features in the Power Platform come together. The view code feature shows you exactly what code is then stored in the solution files.
Development Environments
We’re all faced with the same problem on a daily basis, capacity restraints. Personal developer environments make this problem go away to a certain extent, but sandbox environments can get a little tricky. There are a lot of different ideas as to how sandbox environments should be managed. In a perfect world, these environment types should be disposable. Prior to this Git feature, managing solution artefacts after deployments was a manual job, outside the scope of pac CLI and Build Tools. If you are a low-code developer, you are most likely exporting the solutions manually from an environment as both managed and unmanaged and are storing the artefacts in a SharePoint site, right? Then came along Power Platform Pipelines, where your artefacts were stored in a table aligning version control with pipelines. That made life a lot easier. Now we have the option to have the artefacts in the pipeline, but also the source code in a related DevOps project. These sandbox environments can be deleted after a project, freeing up Dataverse capacity.
Setting Up Power Platform Git
Azure DevOps
There are a few pre-requisites to get started with Power Platform Git Source Control. For starters, you need an Azure DevOps Project with a valid repository. If you have an existing project and repo, you will be able to find it when setting up Git. If not, you can create a project directly in DevOps, and then initiate a repository for this project. Note that any users making use of the Git Source Control feature will also need access to the Azure DevOps project and repo.
Power Platform Git Connection
Next, your environment needs to be managed. If your environment is not yet managed and you begin setting up the Git Source connection, you will be notified that by continuing with the setup, your environment will become managed.
From a Power Platform side, individuals making use of this Source Control feature also require the System Administrator security role for that environment.
To create a new Git connection, head to your solution and select the Source Control icon on the left. Then select Connect.
Define what connection type you want for this Git connection.
Environment: An environment binding connection binds your entire Dataverse environment to the single repository. This means that all unmanaged solutions, objects and customisations within this environment will be stored in a single branch within your selected Azure DevOps repository. It is ideal to use environment binding when you have one or two solutions in an environment and everything needs to be stored in the repo without having to structure separate repos, folders and branches for each solution.
Solution: Selecting the solution binding connection allows you to bind a specific or multiple solutions to separate folders and branches within a repository. This is a great option for when you have multiple people working on multiple solutions allowing you to manage source control per solution and per branch.
If I start with the solution binding connection, I am prompted to select my DevOps organisation. All my projects will become available in the Projects dropdown followed by the repository for that project. I can then select the branch I want to use and provide the Git folder for where the solution will be unpacked into. Once the connection is initiated, you will see the list of changes to the solution.
When selecting the environment binding connection, the same fields are required to be completed, but the connection you establish binds all the solutions in the environment to that repository branch.
Commit To DevOps
Now that I have source control setup for a solution, I can develop in my solution and commit the solution to my repo when I am ready. All I need to do is head to the Source Control pane within the solution and select commit. If you have multiple people working on the same solution, I’d recommend selecting ‘Check for updates’ first.
When ready, just like any other source control, I can select Commit, provide some comments, and the Git Source Control feature will push my updates to my repository and unpack the solution for me as well.
If I head to my DevOps project, I can also view the commits sent to this repo and also view the files unpacked.
Pull From DevOps
When multiple people are working within the same branch and make changes to the solution, be it directly in Power Platform or within Azure DevOps, the ‘Check for updates’ button allows me to see any changes that have been made to the solution. I decided to update my solutions description directly in Azure DevOps, and when checking for updates within the Git Source Control feature, I can see changes have been made and now have the ability to pull those changes into my environment.
If I continue and make a pull request, my solution will update based on the changes made in the branch previously. This now bridges more pro-code and low-code gaps that pro-code tools like pac CLI and Build Tool offer.
Conclusion
As a starting point for low-code source control, I think this Git Source Control feature is fantastic. I foresee a lot of additional features coming in the future similar to how we’ve seen Power Platform Pipelines evolve. I do however feel that there is a larger gap to look at regarding security. Because this feature is using DevOps, managing security for both Power Platform and DevOps can be frustrating. I encountered many errors along the way, all relating to security despite the permissions being set correctly. I hope these are addressed soon.
Hi Nati,
In which way is possible to do the opposite direction: now that solution is in source control, how to put it into a new environment?
Hi.
Once you have committed a solution to source control, you can use Power Platform Pipelines to deploy tue solutions across environments.
https://learn.microsoft.com/en-us/power-platform/alm/pipelines
What I meant is: as another (or same) developer, with a fresh environment, how do I make the solution appear in it so I can develop?
You can create the solution in a new environment and create a Git connection to the same branch, or new branch. Make sure the solution name and publisher are identical to what was committed to DevOps and then check for updates. This should bring in the changes from the branch and allow you to keep your current solution or accept changes from the branch. If you accept the changes, the pull request will update your new solution in the new environment with what exists in that branch.
Thanks for clarifying. I would think that that step was an important part of the development process and would be documented somewhere..
I’ve watched multiple videos and this doesn’t really add any more than them or the MD guides to be honest. They key problem with all of them is “ When multiple people are working within the same branch”. This is not how source control should work – a master/trunk is the source of truth than cannot be committed to, then each developer branches off that for a temporary piece of work. They keep committing until it is ready, then pull request.
I need to test it again now it’s in GA, but this didn’t work in public preview, which totally defeated the point. They claim you can now tie to existing solutions and change branches, so hopefully that’s the answer, but have you tried it? I’ve yet to see much different feedback out there to have a good conversation about this.
I’m sorry to hear this doesn’t cover the depth you’d like. I fully agree that this is not real source control. It’s a version of low-code source control.
In its current state, you can’t tie a solution within a single environment to multiple branches. The design of Power Platform won’t allow this. And sadly, even with solution binding, the environment is bound to the project, but solutions can be bound to separate folders and branches (which I think should be changed).
The approach that Microsoft seems to be proposing, is to manage collaboration at an environment level (I was planning a separate post on this). Each environment has the same solution, but bound to separate branches. Upon merging to main, you can update your branches if necessary and you can then pull all updates back to each developer environment and continue working on what’s been updated.
This is the approach I’ve been testing with and it seems to be working ok with a lot of limitations. I can easily make changes in one environment, commit and merge, then pull those changes into another environment based on a separate branch. Pull requests with Dataverse objects causes havoc though. This Git is really a makers experience for simple canvas apps at the moment in my opinion.
Thanks for replying, it wasn’t a comment on the quality of your article, just that I can’t seem to find answers to true branching strategy.
Sorry if my comment about multiple branches was confusing. I meant essentially what you described in your third paragraph – a golden dev environment point at the master in git, then a developer would branch off that and point each oftheir own development environments to each of those branches, so every environment is still a one-to-one with git. Each developer environment then acts like source code on your individual machine with visual studio for example.
No, the guides seem to imply you can use existing solutions, I want to test this again when I’m back in work, as in theory this should work.
And I think that’s what Microsoft is aiming for. Isolating an environment per branch on a project basis pushing for disposable dev and sandbox environments.
I did test with existing solutions and got a lot of validation errors when trying to pull the branch to an environment. I’m hoping to explore it a bit more in the next few weeks as well.