All-in-one-Deployable Package (ADP)
Introduction
Microsoft has recently released a feature called All-in-one-Deployable Package (ADP).
This is designed to eliminate deployment errors that many programmers deal with and improve deployment efficiency and reliability.
We analyzed how it will impact our projects and how this concept plays a vital role in deployment process. This blog series is as result of our analysis.
We have taken a business scenario to explain how package movement should be carried out before ADP and after ADP.
Scenario: Current model architecture
On an enhancement in Human resource management solution, we have created two new models:
- Time and Attendance and
- PTO Management models
Time and Attendance
Let’s consider Time and attendance model containing elements with respect to employee’s working hours, clock-in, clock-out and time taken on breaks.
- Table – ASCTimeAndAttendanceTable
- Form – ASCTimeAndAttendanceForm
- Class – ASCTimeAndAttendanceClass
PTO Management
Let’s consider PTO (Personal Time Off) Management or Leave Management model with elements handling the employee’s time-off requests, approvals and the utilization.
- Table – ASCLeaveRequestTable
- Form – ASCLeaveRequestForm
- Class – ASCLeaveRequestClass
Let us see how package deployment is done currently and how package deployment should be done after introduction to All in one deployable package (ADP). To make this blog series clear, we have split up this blog content into two-part series:
- Part-1: Current deployment scenarios (Before ADP)
- Part-2: Deployment approach with ADP
Part-1. Current deployment scenarios (Before ADP)
How model movement is done currently (Before ADP)
In order to deploy our code and customizations to a runtime environment (demo, sandbox, production), we must create a deployable package. Currently deployments are carried out in two ways:
- Package generation from Visual Studio
- Package generation from DevOps
Package generation from Visual Studio
In order to deploy our code and customizations to a runtime environment (demo, sandbox, production), we have created a deployable package of our models through Visual Studio Dev tools (Dynamics 365 Menu > Create Deployable package) and then we would upload to the Asset library in LCS.
Package generation from DevOps
Azure DevOps provides pipelines that can be used to automate builds. There are two types of pipelines: YML and Classic. We have followed the classic pipeline which is Team Foundation Version Control (TFVC).
We have installed the NuGet package, built solution/projects, then the new deployable package would be created. We can then publish the deployable package artifact as build output.
If you are following package generation from DevOps, there is no impact of ADP as that packages the entire models at all times.
How it works?
Initial deployment to Production
For the initial deployment process, we have selected all the models i.e. Time and Attendance and Leave Management. So, our deployable package contains both the models.
Going further to add the below changes which we have explained deployment-wise.
Deployment -1: Changes in single model
We have created a new inquiry form to list down employee’s clock-in and clock-out information.
For this, we have created a new form ASCTimeAndAttendanceInquiryForm with existing table ASCTimeAndAttendanceTable as data source.
Our deployable package contains only Time and Attendance model now.
Deployment -2: Change in multiple models
Change Request – 1
A request came in to add a new feature for Work From Home maintenance. In order to accommodate this, we have created a new form ASCTimeAndAttendanceWFHForm with new table ASCTimeAndAttendanceWFHTable.
Change Request – 2
A new validation “Employee cannot take more than 2 days of Optional leave in a year” should be added when an employee creates new leave request.
For this, we have added validation in the ValidateWrite of the ASCLeaveRequestTable.
Both these models would be a part of deployable package.
Now, in Part-2, let us see how the same scenario can be handled with ADP approach.
Part-2: All in one deployable package
What is ADP?
In this concept, we create a deployable package with all the customized models instead of the specific model(s) withour customizations.
We follow same set of procedures here, but we would be selecting all our customized models every time we create a new deployable package regardless of changes being done in the model elements or not.
So, an ADP All-in-one Deployable Package is a software deployable package that contains all the models and binaries that you currently have in an environment.
How it works?
Let’s consider the same set of scenarios we explained in Part-1and try to implement them with respect to ADP (All in one data packages)
Initial deployment /Existing deployment
For the initial deployment process, we have selected all the models i.e. Time and Attendanceand Leave Management. So, our deployment package contains both the models.
Deployment – 1: Changes in single model
For the initial deployment process, we have selected all the models i.e. Time and Attendanceand Leave Management. So, our deployment package contains both the models.
Deployment – 2: Change in multiple models
Change – 1
Employee’s work from home details listed in a new form ASCTimeAndAttendanceWFH with new table ASCTimeAndAttendanceWFHTable.
Change – 2
A new validation “Employee cannot avail more than 2 days of Optional leave in a year” should be added when an employee creates new leave request.
For this, we have added validation in the ValidateWrite of the ASCLeaveRequestTable.
As part of deployable package creation, both these models would be a part of it.
Benefits of following the ADP model deployment approach
This approach helps the multi-member development teams, this process becomes even more important when dealing with multiple sprints, releasing features in parallel as well in Support mode.
This concept helps developers tremendously by drastically reducing the risk of deployment errors and helps with the overall project efficiency.
Some of the common issuesmulti-member development teams face:
- Consider we already moved our deployable package containing Time and Attendance and Leave Management to Test environment.
- We have modified an object ASCLeaveRequestTable in the model Leave Management, based on a Change Request.
If we create deployable package with only Leave management model. When this package gets applied to the Test environment, this would override the already existing solution with both models. As a result, we will only see Leave management and not the Time and Attendance.
Similarly, for the Time and Attendance model.
So, it is important to include all our non-Microsoft models in the package creation hereafter.
Please note: The enforcement of all-in-one packages will be done in phases. The support for current deployable packages ends October 31, 2020.
