You unpack your solution. You commit it to git. You pack and deploy from a pipeline. You tell people you do source-centric ALM.
Where did the unpacked solution come from?
It came from an environment. Someone opened the maker portal, edited a model-driven app or a Flow or a Canvas App, hit save, then exported the solution and unpacked it. The git repo is a record of what an environment contained at a moment in time. The arrow of causality points one way. From environment to source.
That is environment-centric with a git middleware layer. It is not source-centric. The labels matter because the ceremony you build on the wrong label costs engineering budget that does not pay back.
What source-centric actually requires
Source-centric in the way the term has meaning anywhere else needs three things to hold. Source is the truth. The build is deterministic from source alone. Deployment can rebuild any state by replaying the build. When all three hold, environments are interchangeable, branches behave, parallel work is safe, recovery from a broken state is a redeploy.
On Dataverse, the first one fails before you start. Source cannot be the truth for the artifacts that matter most.
Take a Power Automate Flow. You build it in make.powerautomate.com. You connect actions, configure them, save. The platform stores the definition. You cannot meaningfully author that Flow by writing its definition in your editor first. Take a model-driven app. You configure forms, views, business rules, sitemaps in make.powerapps.com. The platform serialises the metadata. You cannot start from the XML. Same for Canvas Apps. Same for business process flows. The unpacked files are downstream of an edit in the maker portal. They are not the substrate of authoring.
Plugins and web resources behave differently because they are real code. You write C# in Rider, compile, deploy. That has been source-centric since 2011 and there is no debate about it. The current source-centric Dataverse pipeline debate is about everything else: model-driven apps, Flows, Canvas Apps, business process flows, security roles, environment variables, business rules. None of those can be authored as source. All of them have to be touched in an environment first. Then unpacked, committed, maybe re-deployed.
That arrow only goes one way.
“But I can pack and deploy from git”
This is the obvious objection. Yes, you can. The deploy works. The label does not.
If you change unpacked files in your editor and re-deploy, you produce a deploy that overwrites whatever is in the target. You have not created an artifact in the way you do when you write a .NET class. You have written a new representation that gets imported and instantiated. For many artifact types, your edits will not survive round trip. The unpacked format is not designed for human edits. The platform reserves the right to reorganise it on the next export.
The real test of source-centric is creating a new artifact from source without ever touching an environment. A new Flow. A new model-driven app. A new Canvas App. Can you do that on Dataverse today? No. The platform requires the maker portal. The platform requires an environment.
So your “source-centric” pipeline is: someone opens the maker portal, makes a change, exports, you unpack, you commit, you pack, you deploy. Strip the ceremony and you have environment-centric with a git layer for audit, collaboration, and deployment. Useful pattern. Not source-centric.
The instinct is imported
Most of the source-centric advocates on Dataverse are experienced architects and ALM specialists. They are not naive about source control. They worked on .NET projects, Java enterprise systems, Azure DevOps pipelines, GitHub Actions setups, where source-centric is the right answer and has been for years. Code, config, and data are separated. The build is deterministic from a folder of files. Branches behave. Diffs are real. Reproducibility is a question of pinning versions and replaying a build.
Those instincts are correct in their original context. The trouble starts when they get transplanted onto Dataverse without checking whether the structural assumptions still hold.
They do not. Dataverse does not separate code, config, and data cleanly. The build is not deterministic from a folder of files because the source files are downstream of an environment edit. Branches do not behave the way they do in Git when the artifacts on the branch are not authored as text. Diffs of unpacked XML or YAML are technically possible and operationally useless for the artifacts that matter.
Smart people keep building source-centric ceremony on Dataverse because the pattern works on every other platform they have used. The pattern is not stupid. The transplant is. The honest move is to take what transfers (C# plugins, TypeScript web resources, Code Apps in TypeScript and React are source-centric anywhere) and reject what does not (Flows, model-driven apps, Canvas Apps, configuration are not source-controllable in the way the imported pattern assumes).
Microsoft has been telling you for years
Microsoft itself has been pointing at this. ALM Accelerator, the most fully realised source-centric kit for Power Platform, is now deprecated. The kit’s own documentation states it: “The ALM Accelerator is deprecated and no new features are being added.” Microsoft directs users to Pipelines and Source Code Integration instead.
Pipelines are not source-centric. They export from a linked dev environment and promote the export. From the docs, in Microsoft’s own words: “Pipelines are intended to simplify ALM for makers. They’re the strategic, in-product experience for maker-initiated ALM in Power Platform.” And on the choice: “Generally, you would choose Pipelines if your organization doesn’t need to control your solutions’ source code files.” Read it twice. The strategic in-product experience is positioned for teams that do not need source control as the deployment driver.
Native Git Integration shipped GA in April 2025. A maker edits in the maker portal, saves, and the solution commits to Azure Repos. Looks source-centric. The maker is still in the maker portal. The dev environment is still where edits originate. Git is the audit and collaboration layer. (Two practical limits worth knowing. Native Git Integration only works with Azure DevOps today. GitHub support is in public preview for June 2026. And from February 2026 Microsoft will start enabling Managed Environments automatically for any Pipeline target environment that is not already enabled.)
Deploy from Git with Pipelines is coming to public preview in June 2026. The release plan reads beautifully: “Source control is the single source of truth across time, versions, and environments.” Strong language. The practical mechanics are quieter. Pipelines gain the ability to use a git branch as a deployment source instead of pulling from a linked dev environment. The contents of that branch only got there because a maker hit Save in the maker portal and Native Git Integration committed it. Deploy from Git is environment-first authoring, git-driven deployment. The deployment story moves toward source-centric. The authoring story does not.
ISVs have a smaller version of the same problem
ISVs are the strongest case for “but my source-centric setup actually works.” An ISV’s entire world is their solution. They build it, version it, ship it to many customer environments they do not own. They do not have to manage anything else in those environments. Their scope of responsibility is bounded by the solution. That is a fundamentally different problem from a customer-side team whose responsibility is everything in their tenant.
Because the scope is so much smaller, ISVs come closer to source-centric than anyone else on the platform. They have fewer files, more control over what gets packed, a real reproducibility need (rebuild v1.4.2 two years later when a customer reports a bug). The pretense holds longer.
But the structural wall is the same. Plugins and web resources source-control cleanly for ISVs and for everyone. Flows and model-driven apps still require the maker portal for authoring. ISVs are not doing source-centric in any deep sense. They are doing source-centric on the parts of their stack that were always source-controllable, and environment-centric on the parts that were not. The structural problem is identical, just spread over fewer files.
Customer-side teams have a fundamentally different problem. They are responsible for everything in their tenant: every app, every flow, every configuration, every integration, every connection, every security role assignment. Their unit of ALM is the environment, not a solution. They want to restore the state of an environment, audit what is configured across the whole tenant, deploy what is actually in production. Source-centric thinking organised around solutions does not address any of that.
Production has irreducible state
Even with disciplined ALM, production cannot be rebuilt from source alone. Not because teams cheat (proper ALM teams do not allow direct production changes). Because production carries irreplaceable state that source does not describe. Real customer data. Live connections to integrations with refresh tokens. User assignments to security roles. App user identities embedded in third-party systems. Audit logs that have already accumulated. Notifications that have already fired.
A pure source-centric rebuild produces a working application with no data, no connections, no users. That is a deployed solution, not a production environment. To get production back, you have to layer state on top of the source-built shell, and the state is what makes production production.
This is structural. It applies to every team, including the ones who do everything else right. Source-centric thinking does not address it.
(I argued the deeper version of this in a previous post on why production is the master branch on Dataverse. The point here is narrower: source-centric cannot fully describe production, by definition.)
The strong view, openly held
I am not opposed to source-centric in principle. I am opposed to forcing it onto a platform that structurally resists it, and I will change my position when the platform changes.
What grates is the pretense. Smart teams build elaborate ceremony, run unpack and pack pipelines, maintain mapping files, keep ALM Accelerator setups running, tell themselves they are doing real source-centric ALM. They consume engineering budget fighting a platform that does not want to be fought. The effort, redirected, would yield more.
Remember the spoon scene in The Matrix? “There is no spoon.” That is the trick here. There is no source-centric Dataverse. There is environment-centric Dataverse with various ways to commit snapshots to git. Accept the platform for what it is, not what you wish it were, and the engineering decisions get easier.
If you are environment-centric, run environment-centric ALM well. That can be Pipelines and Native Git Integration if you are on Azure DevOps. It can be your own Azure DevOps pipeline running Build Tools tasks. It can be your own GitHub Actions setup. It can be your own custom toolchain built on PAC CLI and your own scripts. The tooling choice is yours. What matters is that you accept what you are committing to git is a snapshot of an environment, and you design the pipeline around that reality. Pretending the snapshot is the source is what breaks things.
Where it may change
There are signals. Code Apps (TypeScript, React, built in VS Code) and Copilot Studio agents (YAML definitions, VS Code extension, Git integration) are both code-first by design. When Microsoft builds an artifact to be code-shaped from day one, source-centric works end to end. The difference is that the artifact, not the bolted-on tooling, decides whether the model fits.
Dataverse solutions were not designed that way. The improvements (Native Git Integration, Deploy from Git) are real, and they are not source-centric. They are better instrumentation for an environment-centric platform. Scott Durow brought the pets vs cattle framing to Power Platform in 2020 and argued for cattle. Five years and a lot of Microsoft tooling investment later, the platform has not delivered the cattle for Dataverse solutions. Pets are what it has. Run them as well as you can.
