CI/CD for PowerPlatform: Making changes and merging

 

Now that John and Debbie have there own dev/test instances, and they also have their own development branches in Git (Feature1 for John, Feature2 for Debbie), it’s time for them to start making changes.

John was supposed to add a new entity, so let’s just assume he knows how to do that in the solution designer. Here is how the solution looked like when Feature1 branch was created:

And below is how the solution looks like in DevFeature1 instance once John has finished adding that entity:

John has added that entity to the “Contact Management” application, too, so we can see it on the screenshot below:

Technically, John might have stopped here and just all those changes to the master branch. However, what if John is not the only one who was working on the new Features all this time? Maybe the master branch has already been updated. Besides, Debbie will be in this situation just a few pages later since she will have to apply her changes on top of what John has done so far.

Therefore, it’s time to tackle that merge issues, and, as I mentioned before, here is how I’m going to approach it:

• I am going to use XML merge and assume it’s “supported” if solution import works
• In order to cover that regression question, I am going to test the result of the merge by using a UI testing framework. Since we are talking about PowerPlatform/Dynamics, I’ll be using EasyRepro

 

In other words, what John needs to do at this point is:

• He needs to add a UI test to cover the feature he just implemented. When it’s time for Debbie to add her changes, she will be able to test merge results against John’s test to ensure she does not break anything
• John also need to test his changes against all the tests that have been created so far

 

To do that, John will need to ensure that he is on the Feature1 branch first:

If not, the following git command will do it:

$ git checkout Feature1

There is a test project in the repository which John needs to open now:

Not to make it overly complicated, John will add a test to verify that a new record of “New Entity” type can be created in the application.

The easiest way to do it would be to create a copy of the existing “Create Tag” test – that can be done in the Visual Studio through the usual copy-paste. And, then, there would be a few changes in the code (to update C# class name and to change the entity name that the code will be using):

Once the test is ready, John should run all ContactManagement tests against his dev instance right from the Visual Studio. For that, he will need to use different instance url, so he could use a local test.runsettings file instead of the one used by default. He can do that in the Visual Studio under Test->Test Settings menu:

Turns out there is no problem – both the existing and the new test pass, so John’s changes are good from the regression perspective, and they should also help to ensure that, whoever is making changes next, will be able to confirm the feature John just implemented is still working as expected:

Now that there is a test John needs export solution from DevFeature1 and unpack it on the Feature1 branch.

• To export and unpack the solution, John can use “Export and Unpack” pipeline:

Once the job completes, John can have a quick look at the repository to double check if the changes have been added there:

ita_newentity is there on Feature1 branch. And it’s not there on the master, which is how it should be at this point:

So now John needs to do a few things:

• • Bring over remote Feature1 changes into his local Feature1
  • Merge Master changes into Feature1
  • Commit changes on the Feature1 branch and re-test
  • Commit changes to Master and re-test on the
    Master

 

• $ git add .
• $ git commit –m “New Entity Test”
• $ git pull origin Feature1

 

Once John issues the last command, solution changes will be brought over to the local Feature1:

Time to merge with the master then.

• $ git checkout master
• $ git pull origin master
• $ git checkout Feature1
• $ git merge master

 

In other words, checkout the master and bring over remote changes to the local. Checkout Feature1 and merge in the master.

John can, now, push Feature1 to the remote:

$ git push origin Feature1

Finally, John can go to the DevOps and run “Build and Test” pipeline on the Feature1 branch to see how automated regression test works out on the merged managed solution:

Once the job completes, John should definitely check if the tests passed. They are this time:

And, just to give himself a bit of extra piece of mind, he can also go to the TestFeature1 instance to see that the managed solution has been installed, and, also, that NewEntity is there:

What’s left? Ah, yes… John still needs to push his changes to the master branch.

So:

• $ git checkout master
• $ git pull origin master
• $ git merge Feature1
• $ git push origin master

 

John’s “New Entity” is on the master branch now, yet Build and Test pipeline has kicked in automatically since there were changes committed to the master branch:

That pipeline is now installing managed solution (from the master branch) to the TestMaster environment.

That takes a little while, but, after a few minutes, John can confirm (just like he did previously with TestFeature1) that New Entity is in the TestMaster now:

And the tests have passed:

Actually, as a result of this last “Build and Test” run, since it ran on the master branch, two solution files were created and published as artifacts:

They can now be used for the QA/UAT/Prod.

John can now move on to his next assignment, but I wanted to summarize what has happened so far:

As a takeaway so far(before we get to what Debbie has to do now) I need to emphasize a few things:

• John certainly had to be familiar with Git. It would be difficult for him to go through the steps above without knowing what git can do, how it can do it, what the branches are, etc
• He also was familiar with EasyRepro, and that’s why he could actually create that additional test for the feature he was working on

 

Still, as a result of all the above, John was actually able to essentially bring his changes to the TestMaster instance using git merge, DevOps pipelines, and automated testing. Which means his CI/CD process is much more mature than what I, personally, used to have on most of my projects.

Let’s see how it works out for Debbie (she is on Feature2 branch, and she still needs to add new field to the Tag entity, and, also, to make a change in the related web resource)

Contents:

• DevOps project sample: https://dev.azure.com/itaintboring/_git/CDSDemo
• Part 1: https://www.itaintboring.com/dynamics-crm/cicd-for-powerplatform-round-3/
• Part 2: https://www.itaintboring.com/dynamics-crm/cicd-for-powerplatform-making-changes-and-merging/
• Part 3: https://www.itaintboring.com/dynamics-crm/cicd-for-powerplatform-developing-feature2/