Power Platform ALM: Pipelines, Git Integration and Azure DevOps Explained (2026)

Last updated: November 6, 2026

By ZapAI Team

Power Platform ALM is how apps, flows and agents travel from a maker’s environment to production without anyone editing the live system. Our Power Platform consulting team sees the same turning point at growing companies. One app becomes ten, a flow starts posting invoices, and suddenly a typo in production costs real money. This guide covers managed and unmanaged packages, environments, Pipelines in Power Platform, Git integration, Azure DevOps and GitHub, and which of them a small team actually needs, with every product fact checked against Microsoft Learn on November 6, 2026.

Here’s a pattern we see a lot. Somebody builds a useful canvas app in the default environment. People start relying on it. Then the builder changes a formula on a Tuesday afternoon, the app breaks for forty users, and there’s no earlier version to roll back to. Nobody did anything wrong, exactly. There just wasn’t a process.

Our Power Platform governance guide already covers the CoE Starter Kit, Managed Environments, data policies and the 2026 licensing deadlines. This post picks up where that one stops. It’s about how changes travel. Ignite runs November 17 to 20 in San Francisco, so expect a refresh soon after.

What Does ALM Mean in Power Platform?

Application lifecycle management is the discipline of planning, building, testing, deploying and monitoring changes in a repeatable way. In Power Platform it comes down to four habits. Build in a development environment, package your work, test it somewhere else, and deploy to production by a process instead of by hand.

Microsoft’s package concepts page on Learn describes the deployable unit that every ALM tool in this guide moves around. It’s a container. Tables, forms, canvas and model-driven apps, cloud flows, Copilot Studio agents, environment variables and connection references all go inside it, and the whole container travels between environments as one piece. Microsoft uses its own product term for it. We’ll just say package.

One prerequisite trips people up. Every environment in the chain needs a Dataverse database. If your app lives on SharePoint lists in the default environment, ALM starts with a move, and that’s work our Dataverse services team does all the time.

How Do Managed and Unmanaged Packages Work?

Unmanaged packages are what you build in. Managed packages are what you ship. You develop in an unmanaged package inside a development environment, export it as managed, and import that managed copy into test and production, where nobody can edit its components directly.

The differences matter more than they look.

Read that delete row twice. Uninstalling a managed package deletes the data held in custom tables and columns that belong to it. Clean. Also dangerous, if somebody uninstalls in production to start fresh. Microsoft also notes that you can’t import a managed package into the same environment that holds its unmanaged original, which is one more reason test needs its own environment.

Publishers and prefixes

Every package has a publisher, and every publisher has a prefix that gets stamped onto table and column names. Create your own publisher before you build anything. The built-in default publisher assigns a random prefix like cr8a3, metadata names can’t be changed after creation, and so a table called cr8a3_invoice keeps that name for as long as the environment exists.

Pick one publisher for the company. Microsoft recommends a single publisher because component ownership can’t move across publishers, and one publisher keeps your options open for splitting packages later.

Layers

Dataverse stacks customizations in layers, per Microsoft’s guide to layers and merge behavior. Managed packages sit in managed layers with the most recently installed on top, all unmanaged changes share one unmanaged layer above them, and for most component types the top layer wins. Model-driven apps, forms and site maps merge instead.

So what? A single unmanaged edit made directly in production sits above your managed release and quietly overrides it. Your next deployment succeeds. Nothing changes on screen. That’s the classic ALM bug. Our post on Dynamics 365 CRM customization best practices covers layering from the CRM side.

Which Environments Does a Small Team Need?

Three, at minimum. Development, test and production. Bigger teams add UAT, integration testing or training environments, but most small teams don’t need them yet.

Microsoft’s ALM guidance says any healthy process includes a test environment before production, because the deployment itself needs testing as much as the app does, and a failed test import costs you an afternoon instead of a payroll run.

Development environments changed this year. Microsoft is deprecating unmanaged developer environments, including the free ones created by the Power Apps Developer Plan. New ones can’t be created from November 15, 2026, existing ones are suspended starting December 15, and deletion starts January 15, 2027. Our governance guide covers the conversion steps. The ALM point is simpler. If anyone’s only copy of a project lives in an unmanaged developer environment, export it this month.

A smaller rule. Keep development environments in the same region as production, or on an earlier update station, because importing into an environment running an older version isn’t reliable.

Why Do Environment Variables and Connection References Matter?

They’re what make a package portable. Environment variables hold settings that differ per environment, like a SharePoint site URL or an API endpoint. Connection references let flows and apps point at a named connection slot that gets filled in each target, so nothing is hardcoded to the developer’s own account.

Environment variables come in six types, according to Microsoft’s environment variables documentation. Decimal number, text, JSON, two options, data source, and secret, which reads from Azure Key Vault. Microsoft is blunt about one thing. Include the definition in your package, but not the current value. Remove the value before export, then supply the right one at import or through a deployment settings file, and remember that a changed value can take up to an hour to reach the apps and flows using it.

Connection references have more quirks, listed on Microsoft’s connection references page.

• Flows built inside a package use connection references for every connector.
• Canvas apps use them only for implicitly shared connections, like SQL Server authentication.
• Flows built outside a package don’t convert on their own. Re-import them through an unmanaged package, or follow the flow checker’s prompt to swap connections out.
• Custom connectors need their own package, imported first.
• Canvas apps don’t recognize connection references on custom connectors, so someone re-adds that connection after import.

Whoever turns a flow on must own or have access to every connection in it. Plan that before go-live. A flow that only runs under a departed employee’s account is a governance problem and an ALM problem at the same time, and it usually surfaces on the first day that person’s account gets disabled.

What Are Pipelines in Power Platform, and What Do They Need?

Pipelines are Microsoft’s built-in deployment tool. An admin defines stages like test and production, and a maker deploys a managed package from development with a few clicks. Every environment in a pipeline except the host must be a managed environment, which puts its users in scope for premium licensing.

The licensing rules sit in the FAQ of Microsoft’s pipelines overview. The host should be a production environment and doesn’t have to be managed. Every other environment does. Starting October 2026, the admin deployment page flags pipelines that target unmanaged environments, and admins get 30 days, plus one 30-day extension per environment, before deployments to that target are blocked. Microsoft’s admin deployment page documentation also describes an automatic conversion setting under Deployment settings, set per pipelines host.

One conflict worth knowing. That same FAQ still says developer environments on the Developer Plan can be used without being managed. Microsoft’s deprecation notice says unmanaged developer environments get suspended from December 15, 2026, and that Developer Plan rights don’t cover managed environments. Trust the newer notice. Plan on managed development environments.

What pipelines do well.

• Pre-validation catches missing dependencies before deployment starts.
• Connections and environment variables are collected and checked upfront.
• The same exported artifact moves through every stage in order. Nobody can skip test.
• Every deployment stores managed and unmanaged backups in the host.
• Earlier versions can be redeployed from run history, if that setting is on.
• Delegated deployments run as a service principal or stage owner, with approvals.

And where they stop.

• Managed packages only. No unmanaged deployments.
• One package per deployment.
• No cross-tenant deployments. Microsoft points you to Azure DevOps or GitHub for that.
• Imports run as an upgrade without overwriting customizations, and you can’t change it.
• A single development environment per package.
• Power BI dashboards and datasets, both in preview, aren’t supported.
• No Dataverse table data. Reference data needs another route.

For production, set up delegated deployments with a service principal. That service principal needs Deployment Pipeline Administrator in the host and System Administrator in each target, and approval runs through a Power Automate flow you build on the OnApprovalStarted trigger in the host. Stage owner deployments are simpler but can’t deploy OAuth connection references. Sharing deployed apps and flows with security groups happens only on the first deployment. Pick the right group then.

Use a custom pipelines host, too. It replaces personal pipelines, so admins decide who deploys.

Is Git Integration Ready for Real Teams?

Mostly. Microsoft announced general availability of Dataverse Git integration in April 2025, and Learn now documents both Azure DevOps and GitHub as providers. It needs managed environments for development and target environments, and it’s meant for development environments only.

Setup lives in the packaging area of Power Apps, Power Automate, Copilot Studio and Power Pages. Per Microsoft’s Git integration FAQ, users need System Administrator in the environment to bind it, Azure DevOps Basic access or GitHub repository access, and every user in the environment must meet managed environment licensing. GitHub connects through a GitHub app and Azure Key Vault.

Start with environment binding. It ties every unmanaged package in the environment to one repository folder and branch, and Microsoft recommends it for teams starting out. Per-package binding gives more control but makes makers onboard each new package by hand.

Know the limits before you promise anything.

• One branch at a time. Pull requests and merges happen in your Git provider.
• Commits include every pending change in the package.
• Files are stored as YAML. The pac CLI pack command builds that format, but unpack, clone and sync can’t yet.
• Azure DevOps caps single files near 17 MB after encoding, which can hit large canvas apps.
• No cross-tenant support.
• No tenant setting to switch Git off.

Sources disagree in one spot. Microsoft’s Power Pages enhanced data model page still labels Git integration for Power Pages sites a preview tied to Azure DevOps. Test Power Pages commits before you rely on them.

Git integration isn’t a deployment tool. Microsoft says plainly that test and production shouldn’t be connected to Git. Build a managed artifact and deploy it with pipelines or a CI/CD tool.

When Do Azure DevOps or GitHub Actions Make Sense?

When you need things pipelines don’t do. Think cross-tenant deployments, automated tests, deployments triggered by a merge, code-first components like plug-ins and PCF controls built from source, or a release process that already lives in Azure DevOps or GitHub.

Power Platform Build Tools for Azure DevOps are free, per Microsoft’s Build Tools page, though you need an Azure DevOps subscription. Use version 2, which runs on the Power Platform CLI, because version 1 is PowerShell-based and gets only critical security updates, and you can’t mix task versions inside one pipeline. For authentication, Microsoft recommends a service principal through workload identity federation. Username and password connections don’t support multifactor authentication.

On the GitHub side, GitHub Actions for Power Platform wrap the same CLI and run on Windows or Linux runners. The actions cost nothing, Microsoft’s page notes that GitHub’s free tier includes 2,000 action minutes a month, and the same actions can upload Power Pages sites with a deployment profile too.

Both tools feed environment variables and connection references through a deployment settings file, a JSON file you generate with the pac CLI create-settings command and keep in source control, one per target environment.

Skip the ALM Accelerator. Once the usual on-ramp to this kind of setup, it’s deprecated, and Microsoft now steers people to pipelines, extended with Azure DevOps or GitHub where needed.

Should You Use Pipelines, Azure DevOps or GitHub?

Start with pipelines unless something below rules them out. Add Azure DevOps or GitHub when you need source-driven builds, cross-tenant releases, automated tests or code-first components. Pick between those two based on where your developers already work.

You can combine them. Microsoft’s guidance is to use pipelines for core deployment and extend them into other CI/CD tools when needed. In our practice, the combination that works for most mid-market teams is Git integration in development, a build in Azure DevOps or GitHub, and pipelines for the actual deployment with approvals.

Where Does the Power Apps Checker Fit?

It’s a static analysis tool that scans an unmanaged package for problem patterns before it ships. Run it in development, automate it in your build, and use Managed Environments enforcement to warn on or block imports with critical issues in test and production.

Per Microsoft’s checker documentation, it reviews plug-ins and custom workflow activities, JavaScript and HTML web resources, Dataverse configuration, cloud flows through flow checker, Power Fx through app checker, and desktop flows. Results come with severity, category and a link to the fix. Passing doesn’t guarantee a clean import, since the checker can’t see the target environment.

Enforcement has three levels. None, warn and block. Only critical rules block, and admins can exclude rules they’ve decided to live with. Our advice? Warn in test, block in production, and don’t exclude a rule just because fixing it is annoying.

How Do Copilot Studio Agents and Power Pages Sites Move?

Through the same packages as everything else. Agents and enhanced data model Power Pages sites are both package-aware, so they ride pipelines, Build Tools or GitHub Actions.

Copilot Studio agents

New agents land in the default package automatically, and that one can’t be exported. Set a preferred package before anyone builds. Microsoft’s agent export and import guide lists the rest.

• Exporting and importing needs at least the System Customizer role.
• Use Add required objects so topics, flows and environment variables come along.
• Import custom connectors first, then the agent’s package.
• Topic names containing periods block export.
• Don’t delete topics directly from the package. Change them in Copilot Studio.
• After import, set up user authentication again and publish the agent before sharing it. Icons and channel details may come over empty.

Watch one setting. Microsoft’s block unmanaged customizations feature keeps ad hoc edits out of production, which we like, but its known limitations table says publishing a Copilot Studio agent doesn’t work while it’s on. Test that before switching it on in an environment that hosts agents. Our Copilot Studio vs custom AI agents comparison covers when an agent outgrows this model.

Power Pages sites

Fresh sites use the enhanced data model by default, and on that model the site configuration lives in Dataverse packages and deploys through pipelines alongside the tables and flows it depends on. Site settings can use environment variables, which handles things like identity provider settings per environment. Transactional data in nonconfiguration tables stays out of ALM. Some Dynamics 365 templates still create standard model sites, and those need the older configuration data route. More in our Power Pages customer portal guide.

What Mistakes Break Power Platform ALM?

Five come up again and again. Each one is cheap to prevent and expensive to unwind.

• Unmanaged in production. Edits there become an unmanaged layer that overrides future releases. Remove the unmanaged layer, then turn on block unmanaged customizations where it’s safe.
• The default package. Components built there pick up a random prefix and can’t be exported as a unit. Set a preferred package for every maker.
• Hardcoded values. A SharePoint URL typed into a flow points at the development list forever. Use environment variables.
• The Default environment as dev. Every licensed user can build there, so it’s no place for work you plan to ship. If you’re rebuilding as you move, our canvas vs model-driven apps guide helps you pick the right app type.
• Single-owner everything. Flows, connections and pipelines owned by one person stop working when that person leaves. Use service principals and service accounts for production.

What ALM Maturity Path Fits Your Team Size?

Our view, from ZapAI projects, is that maturity should follow risk and team size, not ambition. A three-maker team doesn’t need branch policies. A 30-developer program does. Here’s the path we recommend, framed as our practice rather than a Microsoft standard.

Most small teams should spend a month at stage one before buying anything. Stage two is where the managed environment requirement bites, so price target environment licenses first, and our Power Platform licensing guide has the numbers. Jumping straight to stage four with nobody to maintain YAML pipelines is the most expensive mistake on this page, because those pipelines rot quietly until the one engineer who understood them leaves and a routine release fails on a Friday afternoon.

A Power Platform ALM Checklist

Use this before your next production release. It’s ZapAI’s working list, not Microsoft’s.

Packages

• One custom publisher with a meaningful prefix.
• A preferred package set for every maker, in Power Apps and Copilot Studio.
• Nothing business-critical left in the default package.
• Environment variable definitions in the package, values removed.
• Connection references named for what they do.

Environments

• Separate development, test and production, all with Dataverse.
• Unmanaged developer environments converted or exported before December 15, 2026.
• Pipeline targets managed, and their users licensed.
• Development never on a newer version than production.

Deployment

• Managed packages only beyond development.
• Pipelines with a custom host, Build Tools version 2, or GitHub Actions.
• A service principal for production deployments.
• Checker on warn in test. Block in production.
• Rollback tested once, on purpose.

After go-live

• Flows turned on by an account that won’t leave.
• Agents re-authenticated and published.
• A written answer to who approves production.

What Could Change After Ignite 2026?

Possibly a fair amount. Ignite runs November 17 to 20, 2026, at Moscone Center in San Francisco, and ALM features tend to move around big events. Treat this guide as a November snapshot. Docs move fast.

What we’ll check first. Whether pipelines gain multi-package deployments or more import options, whether the YAML gaps in the pac CLI close, whether Power Pages Git support leaves preview, and whether the pipelines FAQ gets reconciled with the developer environment deprecation. We’ll update this post when the docs change.

Wrapping Up

ALM for Power Platform in November 2026 is less complicated than it looks. Build unmanaged in development, ship managed everywhere else, keep settings in environment variables and connections in references, and let pipelines carry releases, then add Git integration when more than a few people touch the same app, and Azure DevOps or GitHub when you need what pipelines can’t do. Start small. Stay boring.

ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Power Apps developers and Power Automate team set up environments, packages and pipelines, and our Copilot Studio consultants handle agent deployments. Curious what an engagement involves? Here’s what to expect from a Power Platform engagement. Ready to stop editing in production? Talk to us about a Power Platform ALM setup.

Questions Teams Ask About Power Platform ALM

What is ALM in Power Platform?

Do Power Platform pipelines need Managed Environments?

Is Dataverse Git integration generally available?

Should we deploy unmanaged packages to production?

Pipelines or Azure DevOps for a small team?

Can Copilot Studio agents be deployed with pipelines?

What happens to our free developer environment?