Expanded Configuration Migration Features

[MichaelHolmesWP]

Hi Wael,

I've expanded upon @joshcampbell191 's work on implementing expansion/combine features of Configuration Migration packages by adding more granular control, allowing a user to Split the file to either the Entity level or Record level. Record level was added to provide better VCS visibility of Power Apps portal configuration changes (ie instead of 1 giant annotation_data.xml file containing all the webfile document blobs, you can now split it to per record to make VCS diffs easier to read).

Additionally, I've implemented a "Mapping" feature, similar to how the SolutionPackager works. This was to allow mapping of VCS controlled artefacts (ie Portal WebFile JavaScript/CSS that may be compiled separately) directly into the configuration migration package, either at the data.xml level (Split type: None) or at the Entity/Record levels as per the expand/combine feature mentioned previously. The new script for this is MergeCMData.ps1, with accompanying Commandlets.

For an example of how this / the augmented CM expansion / combination works, please see ConfigurationMigrationTest.cs in the Common Integration test project, along with the Artefacts directory there which has a sample mapping file.

Cheers

Michael

[MichaelHolmesWP]

Bump?

[WaelHamze]

@MichaelHolmesWP thank you for submitting this PR. Apologies it took a while to get to it.

Are you intending to use this purely in Power Shell or you want this to be available via the Azure DevOps tasks too?

A few points for discussion...

1- Regarding record splitting into files, this may make sense for things like annotations but it may make it more difficult to browse through changes for other data types. Are you think of having a separate schema for the annotations? Or will you have everything at record level? 2- The enum (i.e. entity vs record) seems like a good idea, however I suspect that when this get released it would break any existing consumers who are using the cmdlets or scripts directly?

I will take a look at this into bit more details but there are many files to go through :)

[mattp65]

My 2 cents on 1...I like the idea of being able to split out the config by record. This would highlight the individual record more quickly in the diff vs seeing 10 records 'somewhere' in the Snippets file. It would also be valueable for other non-portal type config entities as it again would highlight quicker what changed. Conceptually, its the same as is done with Solution Packager when it decomposes the entity components.

[MichaelHolmesWP]

Hi Wael,

Cheers for having a look mate, been a big fan of toolset for years.

With regards to the enum, my original commits provided backwards compatibility with Josh's original flag but I rationalised that given its a preview feature anyway we could circumvent that with a new task version, happy to add the regression support back in though.

With the entity split level, I feel that the added complexity of separate annotation behaviour would put people off using it. Whilst I built support for re-combining the various levels into data.xml, I still only use the record split for vcs changeset purposes and my ALM still does all external file mapping and rearchiving on the complete data.xml file that is checked in regardless of split level.

The most helpful feature I've found from the build is the solution-packager style external file and record field substitution, which I'll hopefully be expanding upon.

Cheers

Michael

[MichaelHolmesWP]

Moving the changes off master onto a separate branch for the interim, will re-PR the feature branch instead after some more enhancements