D365 Finance & Operations ISV Solution Development Best Practices (Part-2) - Environment Planning & Code Repository

In this blog series we will cover key decision points and best practices in development and maintenance lifecycle of ISV solution for Dynamics 365 Finance & Operations (F&O). The intent of this blog series is to provide best practice recommendations to to potential ISV solution developers to evaluate during their Design, Development and Maintenance product journey.

Full Blog Series Links:

• D365 Finance & Operations ISV Solution Development Best Practices (Part-1) - Develop & Customize Design
• D365 Finance & Operations ISV Solution Development Best Practices (Part-2) - Environment Planning & Code Repository
• D365 Finance & Operations ISV Solution Development Best Practices (Part-3) - Testing Strategy & Release Updates
• D365 Finance & Operations ISV Solution Development Best Practices (Part-4) - Customer Implementation Readiness

Environment Planning & Code Repository Setup:

To start development the ISV solution development an ISV need an access to D365 F&O sandbox, below are steps as guideline to plan the environment needs and setup coding repository of  your product.

• Acquire D365 F&O Trial License: If you are new to ISV development with D365 F&O. You can sign up for trial license to kick off your development journey with D365 F&O. Once you signed up for trial account you can spin off a cloud VM to host your D365 F&O sandbox following the article here. Kindly note the environment (VM) hosted on Azure will be charged to partner’s azure subscription use auto shutdown scripts to control consumption based on need.
• Environmental Planning: Following are suggested ISV to consider in their product development lifecycle. 

(*) As an ISV you can decide to keep a dedicated Build Server to release the final package for distribution. Typically, Customer Implementations also dedicated Build environment. It will depend on your package distribution strategy should you distribute Binaries or Source Codes to customers. Following link is helpful in case you like to create own Build environment.  

 “As ISV grow and evolve, maintaining different releases, bespoke customer specific customizations and patches required more in-depth planning which can be done as product evolved in later stages. More details on Environment planning can be found at following article.”

Code Repository Setup:

Let’s talk about setting up a code repository. Although there are many options and ways an ISV can maintain their codebase. Here is one proposed method whereas an ISV can develop an initial release, publish it and have it deployed to customer base. After the deployment ISV can work in parallel to support current release and servicing existing customers and at the same time work on future releases for feature enrichment. Let’s look at the picture and structure of the code repository.

•  1A: At start ISV developing initial development for MVP release. A repository is created as Main and final codebase is committed here. The purpose of this main repository is the final code for QA before product release and final code for product release will be taken from this branch. You can configure your Build server for product releases on this repo.
•  1B: This will be the development branch where day to day dev work will be done for current product development activities. Once significant dev work is done this is committed to 1A so QA can confirm the final check before product release. It is up to ISV current practices they can do internal QA with 1B release before committing changes to 1A for final System Integration Testing and build deployment for generating distributable binaries / final code.
•  2A: Let’s assume after iterating 1A & 1B, now ISV has a stable MVP / new release for external customers. It is recommended to create a branch of the main release like “Product Release 1.0 – baseline to 10.0.22 D365 F&O release”. Now binaries or code from this will be distributed to customers for all customers conforming to D365 F&O 10.0.22 supported releases. Please refer to Delivering ISV solutions using One Version to understand backward compatibility of D365 F&O releases.
•  2B: Let’s assume after going live consumers of 2A release may face some issues, or you plan to service these customers for minor updates, performance patches, quality updates so corresponding Main branch is setup against this Product Release version which your internal team can validate and test before committing code / release onto 2A branch.
•  2C: This will be standby dev branch in case customer reports an issue of 2A release. Dev team can debug, reproduce, and fix the issue. They will unit test and commit the potential hotfix candidate to 2B. Once ISV approve internal QA for release candidate the hotfix can be published to 2A, and updated binaries / source code can be distributed to customers.
•  3: Sometimes when deploying an ISV at customer side there are customer specific bespoke customizations done on ISV solution in this case recommendation is to create a separate branching structure for this customer.

Summary:

We compiled in this blog recommendations for setting up sandboxes for development and testing and suggestion how to make code repository structure and branches. Evaluate above suggestions in the context of your solution future roadmap and subsequent builds. Following some of above suggestions will help in keeping maintenance cost low and build solution on right foot for alignment with D365 F&O Application Lifecycle Management practices.

References:

• Delivering ISV solutions using One Version
• Partner Sandbox License Request
• Partner Resources for BizApps Products and ISV Development
• Success By Design ISV Connect
• Models and Packages