Plugin development - How to update one plugin step separatedly without affecting other plugin step

[kalluu91]

Hello experts,

Context

My whole team is using the same PowerApps DEV environment.

My team is working on different steps of the same Plugin package (yes, Plugin package, not Plugin assembly).

Each developer is working on his own git branch, so the plugin package is not always the same.

The tool used for deploying Plugin is: Power Platform Tools for VS 2022: https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerPlatformToolsVS2022

Problem

The issue is that when developer A updates his working plugin step, then the plugin step of developer B is updated too. This would overwrite the working plugin step of developer B.

Do you encounter such issues related to development lifecycle like this?

Do you have any solutions/suggestions?

Many thanks,

Kim Anh

[a33ik · Accepted solution]

Hello,

I participated in one project where we had a situation that was similar to yours. Here is what we did to work collectively:

1. Every developer registered their own version of the assembly in the development environment and registered steps against the plugins of this assembly.

2. Once the code was tested and merged into the master branch - the main assembly was built and steps were moved to it.

3. When there was a need to modify the existing plugin - the step registered on a plugin of "main" assembly was deactivated and added to the "personal" version of the assembly again until the moment code is merged to the master.

[kalluu91]

Hello,

By saying 'personal version of the assembly', you mean the developer should create his own Plugin package like `Plugin.DeveloperA` and contains only his working plugin step?

Thanks a lot for your help,

Kim Anh

[a33ik]

@kalluu91 yes, exactly. In this way updates from one developer won't override updates from another developer.

[parvezghumra]

@kalluu91 In my experience, this has been quite difficult to achieve. However, we've managed to work around and/or mitigate against the problem using techniques such as:

1. Planning build team sprints such that only a single developer is working on the plugin assembly/package at any point in time

2. Splitting out your plugin assemblies/package into smaller groups (eg. based on functional/modular boundaries). This would allow for some parallel plugin development to happen

3. Establishing plugin development project structures that mean that business logic and data access logic is separated out into separate projects, allowing them to have automated unit testing applied. This allows for unit testing to be done in-memory without having to actually register the plugin in the development environment. This minimises the time that unfinished code is in the development environment

4. Use a mapping file as part of the solution unpack/pack process in the commit/build process. This ensures that only code that has been successfully merged to the master/main branch is included in the committed solution and therefore integrated into a build for deployment to downstream environments.