In my previous article of the series I've shown my experience with the commit process.

While analyzing the capabilities and limitations of the tool, and trying to figure out how to apply it in a real enterprise level scenario, a few considerations came in my mind that I wanted to share.

⚠️ Manage the versioning process

It's important to be aware that:

  1. Each solution is tied in configuration to a given branch/folder, and as of now, once set, this binding cannot be changed.
  2. All the changes made within that solution are automatically tracked for commit, and you cannot 🍒 cherry-peek 🍒 the items to commit. Is an all-or-none.
  3. As of today there is no way to revert the changes made in your local environment (I mean something like undo pending changes in Visual Studio)

This 3 attention points, together, lead to a direct implication: you cannot work on more than a feature in parallel on the same environment, unless you segment your solutions per feature (and it's quite never a good idea, in my experience), because all the changes on a given solution are committed atomically.

Imagine a situation where you have 👩🏻‍🦰 Alice and 👨🏻‍🦱 Bob. They're working on the same environment, on the same solution (let's call it master). 👩🏻‍🦰 Alice is working on creating a new formula field on the Opportunity table, while 👨🏻‍🦱 Bob is trying to customize the Case entity form with a few custom JSs.

👩🏻‍🦰 Alice's task is quite easy, she finishes early, while 👨🏻‍🦱 Bob one takes a while and requires a few iteration to be considered good for testing.

If 👩🏻‍🦰 Alice decides to commit the changes to the repo, she will see in the Changes tab also the changes made by 👨🏻‍🦱 Bob, that are not yet consistent. 🚩 She will check in inconsistent stuff into the repo.

With the "classical" approach described in the first article of the series, 👩🏻‍🦰 Alice could safely commit only her own changes doing the following:

  1. Execute the changes in the Dataverse, as usual
  2. Locally, in VS/VS Code, run pac solution sync to sync locally all the changes made to the master solution. Here she will download also all the inconsistent stuff made by 👨🏻‍🦱 Bob.
  3. Using undo pending changes feature of Visual Studio on the solution components she didn't touched, she can "revert" only the changes made by 👨🏻‍🦱 Bob that she doesn't want to commit.
  4. Commit and push a consistent solution with only her own stuff.

In fact, the approach proposed by Microsoft in the docs is quite different:

  • Makers (developers) work in isolation in their personal development environments.
  • Makers collaborate via native Git integration, pushing changes to a centralized repo whenever their task is ready, and getting changes from the repo to sync their local environment with the committed changes
  • ⚠️ Pipelines in power platform facilitate deployment automation from source control. Solutions are pushed into target environments via power platform pipelines

This is an ALM process that is quite different from the one pro-devs coming from Dynamics 365 CE / CRM are used to, and there is a key point that today is not addressed: as of today 🚩 you cannot rebuild a solution directly from the sources saved in the repo via native Git integration (this is something that you can/should do, if you leverage the old approach via PAC CLI).

This means you need to have an environment for each dev + 1 "consolidation" environment.

  1. 👩🏻‍🦰 👨🏻‍🦱 Each user commits his own changes when ready,
  2. 🧑🏻‍💻 Then a "team lead" pulls periodically (and manually, because API are not yet available to get this done) changes to the consolidation environment.
  3. 🚄 Once the solution is updated in the "consolidation" environment, a Power Platform Pipeline can be triggered to package the solution as managed and deploy it in the target Test environment (and later, in Production).

🤔 Conclusions

The capability is powerful. It allows makers to collaborate efficiently and unify their efforts simplifying the back-merge process between single developer environments, but:

  • the lack of actual conflict resolution capabilities (read: "merge", or at least "compare")
  • the lack of possibility to build from source code (that it's mandatory if you want to ensure that customizations and custom code are always aligned)

Looks like it's a tool/process designed for citizen devs. I'm still trying to figure out how to make it work in complex, real-life, enterprise scenarios.

❓ And you? What do you think about it? Any idea/suggestion on how to use it effectively in an enterprise solution? Drop a comment here or on my Linkedin page and let me know!

Author Of article : Riccardo Gregori Read full article