Dataverse Git integration (Preview) - The commit process

In my previous article we've seen how to configure Git integration (better be called Azure DevOps integration) on a Dataverse Environment.

Once the connection is set, to trigger your first commit you can open the solution and click on the

On the left navigation pane.

🏗️ Structure of the page

The page is organized like shown in the screenshot below:

On the top there is a command bar with the following buttons:

• Commit: to launch the commit process. More on this later.
• Refresh: can be used to refresh the list of the pending changes. I've already described in my previous article that the actual evaluation of delta between what's in the repo and what's on the environment runs in background. The Refresh button allows to refresh the UI during this background evaluation to see in real time the changes that have been evaluated.
• Check for updates: checks if on the Git repo there is an updated version of the solution that we could pull in our environment (yes, it's two-way)
• Git Connection: just shows a side pane with the details of the integration configured earlier.

Then the main content of the page is divided into 3 tabs:

• Changes: shows the changes that happened in this environment. These are the changes you can commit/push to the repo.
• Updates: shows any item updated on the repository but not in the current environment. You can use this tab to pull those updates locally
• Conflicts: shows any item that results updated in both your environment and the repo, and allows to "resolve" any conflict.

🚀 The commit

If this is your first commit in an already established solution, you probably will end like me, with a lot of stuff in the Changes tab and nothing on the others.

🟢 It may happen the commit button to be disabled, and the warning message in the image below, telling that "Source control components are being processed in the background", is displayed just below the command bar. That's because of the asynchronous changes evaluation process. You need to wait until the process completes before being able to perform your first commit.

🟢 If you click on the Commit button, a side pane appears forcing you to provide a commit message before actually launching the commit process.

The actual commit/push to repo may take a while, depending on the size of the solution and the number of changes you need to push.

🚩 Today there is a strong limit on the size of the commit you can push to the repo. It should be max 25Mb. Considering that the current solution size limit is 92Mb, and it will be extended to 1Gb, I hope this limit will be overcome before going GA.

🧐 Check for updates

🟢 The second tab, Updates, shows automatically any change made by someone else in the repo, that are not currently reflected in the current environment. This matches with the ALM approach proposed by MS that I will discuss later on this post.

You can review the changes then Pull when you're ready.

Please note that it's an all-or-none task. You cannot 🍒 cherry-peek 🍒 what to update.

And what if me and someone else have changed the same solution component?

🥊 Conflict resolution

⚠️ Unfortunately there's no merge capability available so... more then a "conflict resolution", it's like: "let's decide who goes KO".

You have only 2 options available:

• Keep the current changes, discarding the incoming ones
• Accept incoming changes, discarding what you've done so far

🚩 Unfortunately, the current implementation of the feature doesn't allows to preview what changes have been made to the component that has the conflict so... It's a comparison one needs to do manually. More unfortunately, you cannot rely neither on the compare tools available in Azure DevOps, because the source code of your components is available only after you commit, and if there is a conflict you cannot commit... so it's a dog trying to eat his tail.
There is space for an XrmToolbox tool here 😉

Please note that:

1. You cannot commit or pull until you have solved all conflicts
2. The Keep Current Changes and Accept Incoming Changes does practically nothing except moving the conflicting "solution component" in one of the Changes or Updates tabs... only Commit and Pull actions have a practical effect on the repo or on your local environment.

🤔 Conclusions

We've seen the capabilities provided by this new feature. It's a good accelerator, that has room for improvements. In the upcoming articles we'll analyze the ALM process that "arises" from the way these features are implemented, and we'll deep dive on how data is saved in the repository.

Stay tuned! 👋🏻