We can create a customisation that meet customer requirements quickly but they must be maintainable and moved between environments without manual tasks or you create a growing maintenance backlog. The creation of a customisation is only half the work needed.
Lets walk through an example which will show the cost in time of manual data and customisations.
We create a workflow which sends an email to account when a certain field is updated. We create a Workflow in Dynamics 365 and manually create the account in each environment.
You might see this as not being to bad and wondering why Hosk going on about keeping guids in SYNC
- When it comes to guids, take your lead from the boy band NSYNC #HoskWisdom
- When guids are out of sync, manual work is needed every time you deploy #HoskWisdom
or the recent blog posts — Dynamics 365 — Document templates, guids and workflows
What happens next
The account is manually created in
The account will have a different GUID in each environment. Every time there is a deployment to an environments, the workflow needs to be edited, the correct environment account lookup set and the workflow activated.
In this example we will assume it’s a 6 month project. Below we can see the estimated number of builds and manual work needed.
- QA — Every night for 6 months
- UAT — month of UAT — 3 deployments a week
- Training — once a month for 4 months
- Preprod — 6 times
- Production — 6 times
Fixing and activating the Workflow takes 2 or 3 minutes
- QA — 5 times per week, 20 times per month, 6 months = 120 times the workflow was manually updated
- UAT — 12 times the workflow was deployed manually
- Training — 4 times the workflow was deployed manually
- PreProd — 6 times the workflow was deployed manually
- Production — 6 times the workflow was deployed manually
148 times the workflow was deployed manually
if it took 2 minutes then that’s 296 minutes or about 5 hours
if it took 3 minutes then that’s 444 minutes or 7.4 hours
The current cost of creating that one customisation and not creating the data properly and putting it into the ALM process has cost 5 or 7.4 hours and counting. This will continue to take time.
The example doesn’t take into account any bugs which could be created if it wasn’t done or done incorrectly (which can happen with manual tasks)
The correct process
When you create static data or data used in workflows then you should add the data into the ALM process. If you haven’t got an ALM process, read this blog to get started
These tools have data moving DevOps tasks
- Power DevOps Tools by Wael Hamze
- Capgemini Extensions
- Public Preview: Build and Deploy Microsoft Dynamics 365 projects using VSTS
If you don’t have an ALM process, you can add the data with the same guid in different environments, it’s a one off step, which can save you hours. You would need to add this to your environment build tasks so you don’t forget.
Creating customisations is one part of a developing a solution, the maintenance and deploying the customisations between environments is an importance process.
Manual deployments reduce the frequency of deployments (because no one wants to do it) which reduces the testing. Manual deployment steps are boring and can consume hours over a project.
The example is with one customization, on a project you can have tens or hundreds of customisations. The manual tasks can build up to 30 or 40 minutes per deployment.
Manual deployment activities are time consuming, boring and prone to error/people forgetting so make sure you avoid them.