Day to Day ALM for Consultants

In this article we will showcase a possible approach and tool-set that a Functional Consultant could use to take part in our ALM process and ensure their work is committed to source control and automatically and continuously deployed.

Note: There are several tools available that could be used, so feel free to use those with which you are most familiar, just ensure you follow the sequence correctly to minimise the potential for errors and conflicts. No tool-set is foolproof so you should always ensure a robust communication plan is used between all the members of your delivery team

We will cover the following day-to-day activities that a Functional Consultant might perform :

• Connect your workstation to the Git source control repository created in Part 2 : Our ALM Framework and Provisioning Tool
• Customise a PowerApp / Dynamics 365 solution
• Set up configuration data for Export
• Export your Solution and configuration data
• Commit your changes to source control
• Sync your changes AND
• Watch the automated build and deploy !!

Connect your workstation to the Git source control repo

The tool we are recommending for use to manage source control for Functional Consultants is GitHub Desktop, this is a free, simple and easy to use tool that makes it easy to perform commit and sync tasks with your source control repository.

Some other tools you could use (but we won’t cover them here) are Visual Studio Code, Git GUI for Windows or the Git command line

Once you have downloaded and installed GitHub Desktop, you can launch it from your Desktop or Start Menu

Select File -> Add local repository (the repository would have been downloaded when you ran Provision.ps1 in Part 2 : Our ALM Framework and Provisioning Tool, if you didn’t perform that step you will need to choose “Clone repository”)

Enter the local path for the repository (the default location will be “c:\Dev\Repos<name of your repo>”) and click “Add repository”

Your GitHub desktop environment should now look like this :

To connect to the Azure DevOps repository for the first time, click “Publish branch”

As this is the first time we are connecting to Azure DevOps (via GitHub Desktop) it will ask you for credentials. To get the credentials open your browser and go to the Repos tab (this should have been opened for you at the end of the Provisioning script, to access it again click on Repos in your project at https://dev.azure.com)

In the top right hand corner of the Repos page click on “Clone”

From the Clone window click “Generate Git Credentials”

This will provide you with a username and a one-time password

Copy and paste the Username and the Password into GitHub Desktop and click “Save and retry”

Everything should now be in sync and ready to go

Now let’s go and build some PowerApps

Customise a PowerApp / Dynamics 365 solution

Navigate to https://make.powerapps.com, login and ensure you have your Development environment selected.

Select_Solutions_ from the Left hand navigation and open the Solution you selected or created during provisioning, in our case Power Platform DevOps

We currently don’t have anything in our Solution

So let’s add an Entity called “Entity A”

We’ll also add a new field called “Field A”

and put it in the Information Main Form

Make sure to Save and Publish

Let’s create a new Model-driven app so that we can access our new entity

We’ll need to Configure the Site Map

And add Entity A to it (don’t forget to Save and Publish) the Site Map

Then Save, Validate, Publish and Play the new App

Set up configuration data for Export

Let’s create a couple of records in Entity A that we can use as configuration data

The configuration data component of our ALM requires a FetchXML query which we can create by using Advanced Find. Open Advanced Find by clicking the Funnel in the top-right

This should open the Advanced Find for Entity A showing the Advanced Find for Active records (Status Equals Active)

Let’s make sure to add in our new field by clicking Edit Columns then Add Columns and selecting Field A

You can preview the Results if you would like or otherwise just click Download Fetch XML

Now we can go back to GitHub Desktop and “View the files of your repository in Explorer” by clicking Show in Explorer (or open Windows Explorer to c:\Dev\Repos<name of your Repo>

The only folder that a Functional Consultant need to be concerned with is the \Solutions\Scripts folder in your repo and in particular _ConfigMigration.ps1

Open this file in your favourite Text editor or PowerShell ISE, at the same time open the Fetch XML file, that you downloaded earlier, in your Text Editor. In the Fetch XML file, replace all the double quotes ” with single quotes ‘

From this :

to this :

and then copy / paste the Fetch XML into the _ConfigMigration.ps1 file as follows :

Make sure to remove the hashes # from lines 18 and 19 and save the file.

Export your Solution and configuration data

Browse to \Solutions\Scripts\Manual in your repo and right-click on SolutionExport.ps1 and select Run with PowerShell

This will run the same process described in Part 2, which will :

• Connect to your Power Platform Development environment
• Increment your Solution version number
• Export Unmanaged and Managed versions of your Solution
• Unpack your Solution for source control
• Export your configuration data

It will prompt you for your credentials to access your Power Platform Development environment

Sync your changes

Once it is finished you can return to GitHub Desktop, here you will see all the changes including all the Solution components (and Entity A) as well as changes to Solutions\ReferenceData\data.xml (this is our configuration data)

Add a Summary (and optional Description) and click Commit to master (this will commit your changes to your local repository)

Click the Push origin button (either at the top right or in the center window) to sync your changes to Azure DevOps

Watch the automated build and deploy !!

You can now return to your browser and go to the Pipelines page in Azure DevOps and you should see your new commit being built and deployed

Once everything has succeeded it means that a managed version of your Solution is now deployed to your Deployment Staging environment, so you can now go there and see your deployed functionality and data.

That concludes Part 3, in Part 4 : Day-to-Day ALM for Developers we will take a look at how a Developer might use the tools available to deploy Plugins, Web Resources, Customisations and more