Power Platform is fundamentally about low-code, not no-code. It’s a major difference that makes it possible for Microsoft to address such a variety of audiences with a single platform.

The code is there, but the low-code developers and especially citizens rarely need to interact with it directly. There are times when it would be useful for them to see the code - even if they’re not writing or editing it directly.

Ahead of Ignite 2024 conference, Microsoft launched the preview of Git integration in Power Platform. This feature now provides an automated way to make all of the unmanaged code from your Dataverse environment to be visible in a Git repo. No need for setting up any pipelines or custom automations. Woo-hoo!🥳

But wait, didn’t we have Git integration for Power Apps canvas apps already? We did, and I sure hope you didn’t use it for anything important, because it’s gone for good. It was an experimental feature, and those things may never reach production. Such was the case with the first round of PowerGit. For a trip down memory lane, check out the Power Apps Studio and GitHub blog post from Jonas Rapp, almost 3 years old by now.

This time it’s different. I see this as a major step that will help us achieve the long coveted “audit history for metadata” in Dataverse. I believe that it can introduce a whole new audience to the benefits of source control and Git. It is no longer only for people who are writing code. It is also highly beneficial for that growing audience of users who are generating code via low-code or AI tools.

It’s all code. In this first hands-on experiment with the new Dataverse Git integration, I will show how citizen developers can benefit from the ability to see behind the GUI.

Dataverse Git integration in practice

What do we need to ‘Git with it? Here’s the list of current requirements:

• Early release cycle environment

• Dataverse database (obviously)

• Managed Environment enabled

• Azure DevOps project

I’ve got all those, so enabling the feature is easy as 1-2-3. No pro developer skills were required in connecting my Developer environment with a Git repo in Azure DevOps:

The interesting part about the integration is that you can define it either per solution or per environment. Now, the first thought many of you might have is that this is all about ALM and of course solutions should be considered here. That’s not necessarily true.

I see the big opportunity for non-programmer adoption of source control tools when choosing the environment option. That is, just pushing all the unmanaged changes into the Git repo without any solution level controls.

Now, the current UI of the source control integration feature does assume that things happen from under solutions. Even when I chose the environment level setting, to actually commit my changes into Git, I need to navigate to a solution. That’s only natural, though, since of course everything should be built within solutions.

Clicking on “Commit” opens a side pane where a commit comment needs to be entered. The branch selection was done already upon the configuration step, so the low-code devs don’t have to scratch their heads about any of this complex dev stuff. Push the button, code goes into the repo, done!

We must keep in mind that this truly is a preview feature still. My first experience with pushing an empty new solution ended up later pulling in these 9 native Dataverse tables into it automatically:

But anyway…

Working with a canvas app and Git

I used Copilot in Power Apps to generate a nice little 3 table app called “Release Planner”. I did a commit to Git for the initial solution components generated. Let me tell you, a simple canvas app with some Dataverse elements can create a lot of entries in source control. 128 files, to be precise.😯

Let’s think about another stage in the app lifecycle: the inevitable changes. In this case, I decided that the app’s welcome screen should show the title “Release planning app” instead of the default welcome text:

After saving the app and going to see the changes page under the solution source control menu, I was puzzled by why nothing was appearing. Then it dawned to me that perhaps I need to publish my changes to the canvas app, not just save them. That did the trick, and now there was one single component change listed for this environment: my canvas app.

Commit, comment, done. Now, when viewing things from the Azure DevOps repo UI, the Commits screen gives us a nice, detailed view of everything that has been pushed from this Power Platform environment into source control:

Then, when we click on the “renamed canvas app” commit that only included the single change of the title property of the welcome screen header, we discover… 14 changed files. Endless amount of red and green diff data for those files. Doh!😫

This is the “noisy diffs” dilemma that developers have complained about since the XRM days. Now, even though this particular commit contained only the canvas app component, it actually consists of several files that are unpacked before they land in the repo. This is a good thing since the packed .zip wouldn’t be readable.

Viewing all those .json file diffs isn’t all that useful to us. The system ends up making an endless number of little changes to files that have no impact to the app behavior. We just need to ignore the “plumbing” around us and focus on the important bits. But how do we find them?

Change log searching in Azure DevOps

The most common scenario where I’ve previously wished I could browse through the code is when “someone” has changed “something”. New elements appearing in a Dynamics 365 solution that conflict with existing business logic, for example. Pinpointing the exact time and source of these changes would make troubleshooting so much easier. Heck, it might have even been me who made the change, yet how many of us can recall what we worked on last week? Exactly.

Source control to the rescue then! But first: the “fun” thing about Azure DevOps is that the native search feature still doesn’t cover the detailed code within repos. Luckily, there is an extension called Code Search that you (as the DevOps instance admin) can easily install from Visual Studio Marketplace.

Now, once the content has been indexed, we can do searches on the repo contents with the keywords we are interested in. If I want to find out when exactly the visible name of the canvas app had been changed, I can simply type it into the regular search box in the DevOps project. This will take me to a results page that either provides the answer right away, or at least allows refining the filters to get to the exact moment in time when the change happened:

This really is like having the great Dataverse audit history feature at your disposal, but for metadata instead of data in Dataverse tables. Due to how the XRM platform itself has been originally designed, there is no built-in change log or audit trail for seeing when specific solution elements have been created or modified. I bet anyone who’s spent more time with Dataverse and model-driven Power Apps / Dynamics 365 CE apps has wished for such a capability many, many times.

Now it’s here. In preview, and in another service. But still, this is a huge leap compared to what achieving the change log visibility required earlier. Apps, automations, agents - they are just getting smaller and smaller. Plus, there’s soon one billion of them out there to govern. Ain’t nobody got time to manually setup DevOps pipelines for those!

Just like Power Platform Pipelines isn’t the direct replacement of Azure DevOps or GitHub advanced features for bigger projects, the Dataverse Git integration isn’t making them redundant either. What it is doing, though, is expanding the potential audience for healthy ALM practices and reliable source control.

Who’s afraid of Git?

The average power user of Microsoft 365 tools may not feel too comfortable with technologies like Git that have been developed squarely with programmers in mind. It wasn’t developed by just any programmer, either. The Finnish creator of Linux, Linus Torvalds, is also behind Git. Now, just like Linus isn’t necessarily the easiest person in the world to get along with, neither is Git. In fact, in his very first Git commit from 2005 he described it as “the information manager from hell”:

Today, through the rise of GitHub, people outside the initial target group of Git have become aware of the three letters. They may not understand what they really are about (I can’t claim that either), yet it’s a ubiquitous concept in the world of modern computing. If you’re working with low-code apps in the Power Platform ecosystem, many crucial tools like the CoE Starter Kit live their lives on GitHub.

I’ve also heard a more reassuring description of Git than the one used by Linus in his first commit. Someone called it “the OneDrive for Developers”. I think that’s an awesome way to frame it, to make it easier to approach for people who don’t write code (but do create apps these days). A large part of the underlying tech is about keeping track of changes in information and making it available in an organized way across devices and users.

Up until now, my most common scenario for using Git commits has been the detective work that I need to do on the changes in Microsoft Learn content. As an example, if I want to see when certain parts of the product documentation have been added, modified, or deleted, I click the pen icon in the MS Learn article to jump over to the GitHub repo where that content is managed. Sure, it’s not the easiest UI in the world for this purpose, but having access to the exact events when a feature support is introduced, for example, is definitely useful.

There are some tools like Git History that try to visualize the life of GitHub content changes. You can add it as a browser bookmarklet. If you’re using something else, I’d like to hear about it, so please do drop a comment or reply to the newsletter email!

Last week I took the plunge and went from just a GitHub browser to a GitHub publisher. I decided to build a Hugo based static website around the Power BI report that visualizes Microsoft’s Release Planner data. You can read more about it here:

The authoring experience for Hugo websites is just creating and editing Markdown files on your computer. The site settings are edited in a .yaml file. Then, once you’re happy enough with the changes, you just commit the files into a place like GitHub.

Once the changes are in the GitHub repo, Netlify will be triggered by the commit and ensure that the public website is updated with my new content and settings.

In the end, it’s not rocket science. But it does look quite scary if you haven’t been working with these tools in your low-code development or admin tasks before. I reckon the vast majority of Power Platform app and automation makers have not yet had a real use case that would have required them to touch Git.

Maybe now is that time? To “democratize Git”.