How can I compare the same file component between different BUs?

[celirte]

Hi, I have this question, I’m using mcdev and I know how to do retrieve, deploy, build templates and build definitions and everything works great, but I wonder how can I compare the changes between files in different business units? i.e. in the scenario that I create an asset EmailMessage (CustomerKey=12345 and FileName would be like 12345. asset-message-meta.json) in the Dev BU, then when I want to promote it to Qa BU the CustomerKey would need to be something like 123QA (file name like 123QA.asset-message-meta.json and then for the PROD BU it might be something like CustomerKey=123PRD and file name something like 123PRD.asset-message-meta.json, so the 3 file names are different between BUs but I need to keep track from the first time that the file was created in GIT to be able to see the difference, does MCDEV expect some kind of I specify a naming convention for my CustomerKeys? Or how have you managed this scenario for other projects? Thanks.

[dawidmachon]

We're holding the whole retrieve folder in repo for each BU. Then, when we want only part migrations, we're doing branches, and jenkins deploy just 'delta'. Mapping for him is done exactly how you said. _dev, _stg, _prd.

[JoernBerkefeld]

Deploying deltas is the right approach indeed. On my projects i nowadays use a combination of release branches and environment branches. Stuff gets developed on dev branch, then, when a release is ready, we create a new release branch off dev branch. We then switch to that release branch an execute mcdev createDeltaPkg qa (assuming your pipeline is dev > qa >prod).

In our mcdevrc I would have "qa" specified with extra market lists that define dev BU as source and qa BU(s) as target. That way, only changes on dev are found and used to create a deployment package for qa BU(s). Next, we run any pre deployment steps (deletions, rekeying, changes to existing DE fields, creation/setup of things that cannot be deployed).
Finally, we run mcdev deploy cred/bu --validate.

If all went well, afterwards, we then execute mcdev schedule cred/bu -m automation: ... and mcdev publish cred/bu -m journey: ... and mcdev refresh triggeredSend

Sometimes you will note additional manual step. For instance, if you aim to replace one journey with another (not just version, but actual other journey), you would have stopped the old one, which makes it show up in the deploy folder because stopping changes the meta data and you would want to have committed that earlier. Meanwhile, you dont want to "deploy" that journey but just stop it on higher envs...