#MSDYN365BC: Building a Development Environment for Microsoft Dynamics GP ISVs Part 1/3
This is my first foray into the world of Microsoft Dynamics 365 Business Central (BC) development and this series of articles is meant to help Microsoft Dynamics GP ISVs understand the process of building a BC development environment, identify similarities with a Dynamics GP development environment, and fully utilize your accumulated experience. Yes, there's tons of literature out there, but none have the perspective of a GP ISV, so there's that 😋
It is worth noting that I am a 20+ years Microsoft Dexterity developer and, as we say, "we do things a little different around here" in the Dex world, but I am very excited to be initiating this new chapter in my career.
As you all know, at this point in my life I manage the Software Engineering team at Mekorma and as a long time Microsoft Dexterity developer they were a few things I knew I wanted out of this new development environment:
Isolation
From an engineering perspective, this means that each developer needs the ability to author and unit test code locally, while ensuring changes are managed centrally in our Azure DevOps source code repository. This is how we've always done it in the GP world and I did not want my engineering and development team to have to learn new paradigms or think differently about the actual process.
I know, I know... a lot of you prefer to have development images in the cloud and have developers connect to those images and develop from there. This is a personal preference and you need to evaluate what works for your development team. In our particular case, we don't want to be reliant on internet connectivity to have a developer do their work. Some of the best pieces of code have been created when folks are sitting at the beach sipping pina coladas, or while in the mountains in a cabin, so there's that.
Ease of Deployment
One of the things I truly dislike about the process of building Microsoft Dynamics GP integrating applications, after all these years, is the need to have several versions of Dynamics GP and Dexterity installed on each developer's machine, depending on the release of GP being targeted. If your company is anything like ours, as of this writing, we support anything from GP 2013 R2 to GP 2018 R2 and everything in between. That's a lot of software!
Having all these instances of GP involves a lot of application installation, service packs, etc., not to mention SQL Server and a variety of versions and builds of your own product, which quickly adds up in terms of time and productivity.
NOTE: We have simplified a lot of these headaches by having a single code base source code repository of our products for all versions of Dynamics GP, but it still does not mitigate the effort of installing all GP versions.
For BC, we wanted something self-contained, much simpler to maintain, that could easily be folded and recreated if needed, without burdening the developer with long winded software installations.
Resilience
Paramount to the development environment is the ability to add features to different versions of BC without having to do any sophisticated branch management. With Dexterity, you have to branch the whole project and not just specific components in order to move to the next build. This is an issue, because, overtime, there are too many branches to manage. The idea of only branching the software components to be enhanced sounded very appealing, making the development environment and process, resilient in the long run.
Given all these requirements, we opted for deploying Business Central Docker images as this would provide the best of all worlds. We also would reserve the online Sandbox for our Sales and Support teams to test and learn new product features while allowing us to continue develop and test without interruptions.
The first task at hand then, is the installation of Docker and download the BC container images. To keep each topic separated, please read Part 2 in this series.
Until next post,
MG.-
Mariano Gomez, MVP
It is worth noting that I am a 20+ years Microsoft Dexterity developer and, as we say, "we do things a little different around here" in the Dex world, but I am very excited to be initiating this new chapter in my career.
As you all know, at this point in my life I manage the Software Engineering team at Mekorma and as a long time Microsoft Dexterity developer they were a few things I knew I wanted out of this new development environment:
Isolation
From an engineering perspective, this means that each developer needs the ability to author and unit test code locally, while ensuring changes are managed centrally in our Azure DevOps source code repository. This is how we've always done it in the GP world and I did not want my engineering and development team to have to learn new paradigms or think differently about the actual process.
I know, I know... a lot of you prefer to have development images in the cloud and have developers connect to those images and develop from there. This is a personal preference and you need to evaluate what works for your development team. In our particular case, we don't want to be reliant on internet connectivity to have a developer do their work. Some of the best pieces of code have been created when folks are sitting at the beach sipping pina coladas, or while in the mountains in a cabin, so there's that.
Ease of Deployment
One of the things I truly dislike about the process of building Microsoft Dynamics GP integrating applications, after all these years, is the need to have several versions of Dynamics GP and Dexterity installed on each developer's machine, depending on the release of GP being targeted. If your company is anything like ours, as of this writing, we support anything from GP 2013 R2 to GP 2018 R2 and everything in between. That's a lot of software!
Having all these instances of GP involves a lot of application installation, service packs, etc., not to mention SQL Server and a variety of versions and builds of your own product, which quickly adds up in terms of time and productivity.
NOTE: We have simplified a lot of these headaches by having a single code base source code repository of our products for all versions of Dynamics GP, but it still does not mitigate the effort of installing all GP versions.
For BC, we wanted something self-contained, much simpler to maintain, that could easily be folded and recreated if needed, without burdening the developer with long winded software installations.
Resilience
Paramount to the development environment is the ability to add features to different versions of BC without having to do any sophisticated branch management. With Dexterity, you have to branch the whole project and not just specific components in order to move to the next build. This is an issue, because, overtime, there are too many branches to manage. The idea of only branching the software components to be enhanced sounded very appealing, making the development environment and process, resilient in the long run.
Given all these requirements, we opted for deploying Business Central Docker images as this would provide the best of all worlds. We also would reserve the online Sandbox for our Sales and Support teams to test and learn new product features while allowing us to continue develop and test without interruptions.
The first task at hand then, is the installation of Docker and download the BC container images. To keep each topic separated, please read Part 2 in this series.
Until next post,
MG.-
Mariano Gomez, MVP
Comments