Use Solution Packager in a shared developer environment

Imagine a scenario where multiple developers are collaborating on a single Dynamics 365 solution within a shared development environment. When one developer completes their work, such as implementing an assigned user story, they need to upload their changes to the repository and deploy them to the test environment. Crucially, this must be done without including any changes made by other developers, whether those changes are complete or still in progress.

One effective approach is to leverage tools such as the Solution Packager. Using tools such as this, the developer would

1. unpack the solution (e.g. Contoso in Figure 1) from the shared developer environment using the Solution Packager
2. compare (using a tool such as WinMerge Figure 3) the unpacked solution to the one already stored in the products-contoso repository (Figure 1)
3. identify the changes the developer has made to the solution (whilst ignoring changes made by other developers)
4. update the products-contoso repository with the identified changes
5. pack the solution with the files stored in the products-contoso repository using an Azure DevOps build pipeline Build an Dynamics 365 solution via an Azure DevOps pipeline.
6. deploy the solution zip to higher environments using an Azure DevOps deploy pipeline Deploy a Dynamics 365 based solution via an Azure DevOps pipeline

Examples

The following examples describe what a developer needs to look for when they are trying to manually identify changes that they’ve made to the Contoso solution. That is, when they reach points 3 & 4 (listed above) in the process

1.) Removing a lookup attribute

2.) Adding a business process flow

3.) Adding an action

4.) Associating a Task Activity to a custom entity

1.) Removing a lookup attribute

Scenario

Consider an entity called cpl_noncompliance. This contains an attribute called cpl_stationid which is a lookup to an entity called cpl_station. In the shared development environment, the developer removes this attribute from the cpl_noncompliance main form and then removes this attribute from the entity cpl_noncompliance. These changes then need to be deployed into the higher environments

Steps 3 & 4 of the process

After the Contoso solution in the shared development environment is unpacked by the developer, the following changes (which were caused by removing the attribute) would need to be manually identified by the developer. Then the products-contoso repository would be updated with these identified changes

• the attribute cpl_stationid being removed from this files
  /Solutions/Contoso.Entities/cpl_noncompliance/FormXrm/main/{…
  /Solutions/Contoso/Entities/cpl_noncompliance/Entity.xml

• the file being removed i.e.
  /Solutions/Contoso/Other/Relationships/cpl_station.xml (assuming the entity cpl_station isn’t referenced in any other lookup)

• a line referencing the relationship between the two entities being removed from the file
  /Solutions/Contoso/Other/Relationships.xml

• the entity cpl_station being removed from
  /Solutions/Contoso/Other/Solution.xml (assuming it was also removed from the solution in the shared development environment)

2.) Adding a business process flow

Scenerio

Consider a business process flow cpl_noncompliance bpf which needs to be created and associated to the entity cpl_noncompliance. When the developer does this, the changes then need to be deployed into the higher environments

Steps 3 & 4 of the process

After the Contoso solution in the shared development environment is unpacked by the developer, the following changes (which was caused by creating the bpf) would need to be manually identified by the developer. Then the products-contoso repository would be updated with these identified changes

• the folder being added
  /Solutions/Contoso/Entities/cpl_noncompliancebpf

• changes to the following files being added
  /Solution/Contoso/AppModules/cpl_contosoapp/AppModule.xml
  /Solution/Contoso/Entities/cpl_noncompliance/Entity.xml
  /Solution/Contoso/Other/Relationship/cpl_noncompliance
  /Solution/Contoso/Other/Relationship/Organization.xml
  /Solution/Contoso/Other/Relationship/ProcessStage.xml
  /Solution/Contoso/Other/Relationship/SystemUser.xml
  /Solution/Contoso/Other/Relationship/Workflow.xml
  /Solution/Contoso/Other/Relationships.xml
  /Solution/Contoso/Other/Solution.xml

• The following files being added
  /Solution/Contoso/Workflows/NonComplianceBPF-BA99F07E-278B-ED11-81AD-00224818A6D6.xaml
  /Solution/Contoso/Workflows/NonComplianceBPF-BA99F07E-278B-ED11-81AD-00224818A6D6.xaml.data.xml

Note: when updating the products-contoso repository, there would be no need for the developer to:

• update the file /Solutions/Other/Customizations.xml because this is automatically updated by the Solution Packager when packing the solution zip
• add any of the missing dependencies in /Solutions/Other/Solution.xml. That is, adding the dependencies between the tags <MissingDependencies></Missing Dependencies>

3.) Adding a action

Scenario

An action needs to be created. As part of creating the action, the following step needs to be registered

• CPL.Contoso.Plugins.Task: cpl_managetasks of any Entity

After the developer registers this step using the ‘Plugin Registration Tool’. The developer then adds the registered step to the Contoso solution by going to the classic view and adding it in the ‘Sdk Message Processing Steps’ section. These changes then need to be deployed to the higher environments

Steps 3 & 4 of the process

After the Contoso solution, in the shared development environment, is unpacked by the developer, the following changes (which were caused by creating the action and registering the step) would need to be manually identified by the developer. Then the products-contoso repository would be updated with these identified changes

• adding/updating the following files
  /Code/Contoso/Plugins/Entities/task/Task.cs
  /Code/Contoso/Plugins/Plugins.csproj
  /Solutions/Contoso/Other/Solution.xml
  /Solutions/Contoso/SdkMessageProcessingSteps/{9302b656-3ae2-ed11-7794-00114828a014}.xml
  /Solutions/Contoso/PluginAssemblies/CPL.Contoso.Plugins-3392AC1D-5C00-482C-A330-5AF1512F36D/CPLContosoPlugins.dll.data.xml
  /Solutions/Workflows/ManageTasks-49EB03D-52E2-ED11-7747-00114818A012.xaml
  /Solutions/Workflows/ManageTasks-49EB03D-52E2-ED11-7747-00114818A012.xaml.data.xml

Note: The plugin CPL.Contoso.Plugins.dll isn’t stored in the repository because it’s built by the build pipeline and included in the solution zip via Solution Packager and Mapping.xml

4.) Associating a Task Activity to a custom entity

Consider the situation where the Task activity needs to be associated to a custom entity called Non-Compliance. That is, there is a requirement to set the ‘regarding’ polymorphic lookup of Task to the Non-Compliance entity. (Figure 2)

To achieve this, the following setting needs to be checked on the Non-Compliance entity (Figure 3). This results in the following change in the underlying entity xml (Figure 4)

References

https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/reference/solutioncomponent?view=dataverse-latest

Set up Tasks for your Model-Driven Power App – Power Addict Ben (bendenblanken.com)