Dynamics 365 Version Numbers & Solution Management

A couple of little notes before we get into this blog - I've been doing them on the Microsoft Community site now for nearly a year and we have just passed 27,500 views which for a little guy from the middle of nowhere in Scotland is surreal but I've been quiet recently doing some revision for the Dynamics 365 Customisation and Configuration (MB2-716) exam. The exam itself concentrates a lot on Solution Management which brought me back to my old thinking that numbering and notes on solutions isn't really done any more. Normally I give tutorial blogs on setting up new functionality but hopefully this one will stir some thought and maybe set some processes or good housekeeping on the go.

Solution Types

Based on the TechNet Article (https://msdn.microsoft.com/en-gb/library/gg334576.aspx) 

Solutions are how customizers and developers author, package, and maintain units of software that extend Microsoft Dynamics 365 (online & on-premises). Customizers and developers distribute solutions so that organizations can use Microsoft Dynamics 365 to install and uninstall the business functionality defined by the solution.

There are two types of Microsoft Dynamics 365 solutions: managed and unmanaged. A managed solution is a completed solution that is intended to be distributed and installed. An unmanaged solution is one that is still under development or isn’t intended to be distributed. When the unmanaged solution is complete and you want to distribute it, export it and package it as a managed solution.

Solution Numbering

I am a firm believer in control and versioning - Personally I use the Major.CRMRelease.Minor.Release (1.00.000.00000) , So currently this would be 1.82.000.0000 as my base build (as I am building on 8.2)

• Major - If there is major functionality added to the system or if there are multiple project phases, So phase 2 of my project would update the numbering to 2.00.000.0000
• CRM Release - This would be the CRM Version that the solution was built using so updating the version number to 2.82.000.0000
• Minor - Minor changes I emphasise the changes part, If a change request comes in this adds to the solution then we increase this number. so after 37 change requests are signed off we are sitting at 2.82.037.0000
• Release - Bug Fixes, any time you fix something that is not working either via support tickets or consultancy issue lists then we increment this number. We have had 44 support tickets and 12 project issues so when the customer goes live we are running solution 2.82.037.0052

I have also used it a little differently back in the day where I would have Major.Minor.Release with the CRM Release number being rolled into the release number. Breaking down the Major.Minor.Release structure my ideal scenarios are as follows

• Major - If there is major functionality added to the system or if there are multiple project phases, So phase 2 of my project would update the numbering to 2.00.82000
• Minor - Minor changes I emphasise the changes part, If a change request comes in this adds to the solution then we increase this number. so after 37 change requests are signed off we are sitting at 2.37.82000
• Release - Bug Fixes, any time you fix something that is not working either via support tickets or consultancy issue lists then we increment this number. We have had 44 support tickets and 12 project issues so when the customer goes live we are running solution 2.37.82052

Now some people will do this through UAT and testing then reset when you go live - I personally won't do this as with iterative builds it is hard enough to keep your place.

Comments & Notes

Have you ever taken a project over from another consultant or company? Find it hard to process decision making and end goals?

There are lots of places to keep notes that are helpful and can actually be used for basic release notes. I use the solution description to keep myself and anyone else on the project right. I will admit it can be time consuming if you are just nipping in to do a little change but 4 or 5 little changes by several different consultants will result in things that people will need to ask questions about - for me it is better to take 2 minutes to add some description than it is to answer 10 emails on the subject 6 months down the line. 

Here is my example

Workflows

I know unpicking workflows and working them back to find out what they should be doing is your favourite post 9pm activity but if you have a little compassion for your fellow consultant then you can add some reasoning or description into the workflow - Again this is only my personal preference but I will copy either the user story that it relates to or the change request into the description. It will also help with Scope creep or changes to spec.

Other Considerations

These are not my ideas but with some great peers I have worked with there are lots of ideas,

Here is a selection

• Keep Workflows in a separate solution
• Reset version numbers after each CRM release
• Reset version numbers back to 0 for go live

Final Thoughts 

My last one that I will leave you with and it is related - The structure I would recommended for Dev/UAT/Live would be to have a Unmanaged Solution in Dev, This exports as a Managed solution to UAT, When the UAT is signed off that same managed solution is then imported into Live.

This way there are no on the fly changes that end up in UAT that are overwritten when you have your next dev release.

Until next time................