Non-Techie Guide Part I: Developing in Dynamics 365 Business Central Online

As a long time user of Navision, Dynamics NAV or Dynamics 365 Business Central or other on-premise business solutions, you will be used to being able to get customisations quickly developed and deployed. However you will also have seen the difficulties that this has caused further down the line as in older versions development involved amending the very core of the product – it was flexible and quick to do, but extremely difficult to reverse and problematic for upgrades.

Once you move your solution online (aka SaaS or Software as a Service environment) you have no choice but to take frequent software updates – usually monthly with major releases twice a year. Every piece of custom development that you do adds complexity to your solution and makes both updates and support riskier and more complex.

If you are doing regular, custom development then a scatter gun approach with everyone shouting their requirements and declaring them to be urgent is a recipe for disaster. Having multiple inter-dependant changes in a sandbox (aka test) environment is an absolute no-no – and trying to cherry pick one of them to put live is fraught with potential issues. So we recommend adopting a build and release strategy that works with your business requirements.

Build and Release Strategy for the development of Dynamics 365 Business Central

You need to look ahead, plan required developments for the coming months, then group changes together based on priority and dependencies. You also need to consider the application areas affected and group based on ease of development and testing (a release cycle or “sprint”). If urgent changes are required such as a bug fix then this should be pulled into an interim release and other development must go on hold. This means creation of a new sandbox from live with only the interim release and getting that tested and into production before going back to the development cycle. Remember though that the ongoing development will need to be deployed to a new sandbox (created from the now updated production environment) and retested and potentially reworked. If this can be avoided and fixes built into the next release cycle, this is a more efficient approach.

However, keep releases cycles at a manageable size. If you try and make too many changes in a release cycle then it will take too long to go through the development, testing and refinement cycle and will present a bigger risk on go live, becoming a marathon rather than a sprint!

Plan development release cycles around major releases (April and October) – on release of an update a new sandbox will be created which will be a copy of the production environment and will be updated to the new version ready for testing. This effectively creates a development freeze, meaning nothing new should be deployed to production until after the release has been pushed to live. For minor releases this will be just a few days, for major releases this will be around 2 weeks.

Whether your release cycles are 1 change a year, or several changes a month, planning and organising them in the most efficient way will save cost and time, whilst also reducing risk.

Fancy a bit more in-depth insight into the customisation of Dynamics 365 Business Central online? Then tune in to one of latest Tecman Talks Dynamics podcasts, entitled “The Challenges of Development” at www.tecman.co.uk/podcasts

For part II of this blog click here.