Using Solution Packager in a shared developer environment
Dustin Miner
- posted on
- Comments Off on Using Solution Packager in a shared developer environment
Introduction
Consider the situation where multiple developers are working on one solution in a shared development environment. When a developer is finished making their changes to the solution (e.g. a user story they have just implemented). They want those changes deployed, without deploying changes that other developers have made, or are currently making to the solution
One option to meet this requirement is to use the Solution Packager. Consider an example of where a Dynamics 365 solution called Contoso has been unpacked by the Solution Packager and stored in the products-contoso repository – Figure 1
The process for the developer to follow would be to
- unpack the Contoso solution from the shared developer environment using the Solution Packager
- compare (using a tool such as WinMerge Figure 3) the unpacked solution to the one already stored in the products-contoso repository
- identify the changes the developer has made to the solution (whilst ignoring changes made by other developers)
- update the products-contoso repository with the identified changes
- pack the solution with the files stored in the products-contoso repository. This is a validation step to ensure there are no issues i.e.
- the build pipeline will be able to pack the solution zip with files stored in the products-contoso repository Creating an pipeline to build a Dynamics 365 based solution. (The deploy pipeline will then be able to deploy the solution zip into the higher environments.)
Examples
The following examples describes 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
Set up Tasks for your Model-Driven Power App – Power Addict Ben (bendenblanken.com)
