With the current fast appearance of new versions of D365 FO (10 times a year). Testing can become more time consuming. So, you must decide:
- Skip updates, take for example only the even or odd platform update numbers
- Do not test and have confidence at MS. But please be aware at MS they are also mere humans and humans make mistakes.
- Increase your Test team so more tests can be performed in a shorter time.
- Start using the Regression Suite Automation Tool.
In the past we chose option 1. We did still release every month, but the release of MS was not included the releases with ISV and tailored solutions for the customer.
How we use it
When we start talking about RSAT with the customer, they always reply, that there is no budget. This is not correct, there are always costs on testing. Only the current test cost is hidden within the organization of that customer in the form of internal tests and/or issues arising in production environments. What we see is that the customer has a budget for his IT projects. The hours that the customer/key user is testing is not part of this budget.
Then we see another point, the current task recordings are most of the time outdated (see blog Why should your Business Process Modeler (BPM) be up to date?). By using RSAT you are automatically being forced to bring your BPM library up to date.
RSAT can become even more powerful by using it like a provisioning tool. Below is an example as we use it in a release pipeline. The first example is when we restore a database on a tier 1 box (MS hosted, or customer hosted)
The current RSAT solution needs to be installed on an actual machine instead of running as a cloud service. To achieve this we installed it on a cloud hosted Devbox and turned on auto shutdown to manage costs. Therefor you see steps both starting and stopping said environment in the train.
The current RSAT on a devops only runs on a real machine where it is installed. So, we installed it on cloud hosted Devbox, to keep the Azure cost low we start that VM on demand. In the Parameters of the RSAT provisioning we select the RSAT settings file pointing towards the environment we just restored the database of.
The tasks we use RSAT for are:
- Enable users
- Start batches
- Update exchange settings
- Any other integration options
But RSAT is also reusable when you deploy a new release with your latest tailored customer code. The reason I use RSAT this way is, testing on a Tier 1 is not representing the world, I want to test the Package in the Operational area and not in the Development area.
And the last case is for updates of Microsoft. It is similar like above , you only run the RSAT task on the MS release candidate environment.
So now that the business case has been explained, let us have a short look at the building blocks.
For starting and stopping the VM we use Azure CLI
Agent Pools
The steps we used need different Agent pools. I always prefer to use only the azure Pipelines. But those have a limitation. In case the step needs programs or files that are located on the VM, the VM also need to become an agent pool. Below list shows the additional agent pools we need at a customer implementation
And when you realize you need a building pool on an existing cloud hosted or even running on a local VM, you can still install it. Look for information on https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
And now to wrap up; RSAT does not need a Sales story. If you know how to use it, It will start selling itself.
For other DEVOPS tips have a look at https://kaya-consulting.com/category/lcs/