TL;DR

You can integrate Azure DevOps with GitHub to get the best of both worlds in Power Platform development.

• ADO stays as the backbone: work items, sprint planning, test plans, and deploy pipelines all remain on Azure DevOps.
• Code moves to GitHub: Power App Code Apps or Power Pages SPA live in GitHub repos, unlocking native GitHub Copilot integration and the Copilot Cloud Agent.
• The two platforms are linked: commits reference ADO work items via AB#{id}, creating a bidirectional traceability layer.
• The Copilot Cloud Agent works autonomously: assign it a task, it opens a PR; assign it to a PR, it reviews and fixes issues — all guided by your repo's own instructions.

---

Managing ALM on Power Platform has never been straightforward. Anyone who works seriously with CRM and business applications knows it: an application's lifecycle doesn't end when the code is written. Requirements, sprints, pipelines, tests, reviews — everything needs to fit together coherently. And for years, my answer to that problem has been Azure DevOps.

🏗️ The starting point: Azure DevOps as the backbone

Azure DevOps has always given me what I needed: Work Items for tracking requirements, Git repositories, CI/CD pipelines, integrated test plans. A complete ecosystem built for teams that want full control over the application lifecycle — from user stories all the way to production deployment.

For Power Platform applications ADO remains a rock-solid choice, whether you're building canvas apps, model-driven apps, or Power Pages portals. Solution pipelines, ALM tooling like Power Platform Build Tools, and native environment integration make the workflow reproducible and governable.

All good.

Then came the Power App Code Apps and Power Pages SPA.

🎮 New App types are changing the rules of the game

Power App Code Apps and Power Pages SPAs represent a paradigm shift: you're no longer working with a low-code designer, you're writing real code — TypeScript, React, custom components. And when you write real code, AI in the development cycle stops being a luxury and becomes a genuine accelerator.

They benefit enormously from AI in their development cycle: code completion, automated review, test generation. This changes the weight of your platform choice significantly.

By company policy, our trusted assistant is GitHub Copilot. And here's where the first point of friction emerges: GitHub Copilot lives on GitHub, not on ADO.

💎 GitHub is more than just a repository

In recent months, with the introduction of the GitHub Copilot Cloud Agent, the platform has taken a significant leap forward. GitHub is no longer a mere Git repo storage: it's an autonomous agent platform, that is able to run agents in the cloud, in the background, like real collaborators.

However, GitHub doesn't match ADO's completeness for the rest of the lifecycle: requirements management, sprint planning, structured test plans — what an enterprise team needs to govern a complex project remains ADO's strong suit.

The question I asked myself was: can I get the best of both?

🔗 The hybrid setup: ADO + GitHub integrated

The answer is yes — and the setup is less complicated than it might sound. Azure DevOps and GitHub integrate natively. Once the connection between the two environments is configured, the two systems start talking to each other bidirectionally.

Code lives on GitHub. Work items, requirements, sprint planning, test plans — everything stays on ADO. Deployment pipelines to Power Platform keep running on ADO Pipelines, with the connectors you already know.

↔️ The bidirectional link in commits

One of the things I cared most about was not losing the connection between code and work items. In pure ADO, this works naturally: a commit can reference a work item and build a traceable link. I wanted the same result in the hybrid setup.

And I have it. The syntax to use in commit messages (or PR comments) is straightforward:

In GitHub commits, use the AB#{WORKITEMID} syntax to automatically link the commit to the corresponding work item on Azure Boards. The link appears on both sides, bidirectionally.

Writing fix: error handling on component init AB#1234 in the commit message is enough to create a traceable link between the code change and the ADO task. The integration automatically populates the "Development" section with a reference to the commit or PR.

Anyone who works with ADO knows how important this kind of traceability is during audits, release planning, or simply when trying to understand "why was this code written this way."

🤖 The Copilot Cloud Agent: a collaborator that works while you sleep

This is the part that genuinely changed how I work. The GitHub Copilot Cloud Agent can be assigned directly to a bug or a task — and from that point, it starts working on it autonomously, opening a Pull Request and building the solution in the background.

The quality of the output depends heavily on how you write the task. A well-structured issue — with clear context, acceptance criteria, and references to the existing codebase — produces a significantly better PR than a vague, one-line title. The investment you make when writing the task pays off when the agent delivers the work done.

But the most compelling part is the automated Pull Request review. The Copilot Cloud Agent:

• analyzes every PR opened by developers,
• anticipates problems,
• flags questionable patterns,
• and can be actively engaged to fix them — all inside the PR, in comments, in a collaborative way.

🎯 Contextual review, not generic feedback

There's one aspect that sets this configuration apart from a generic "AI that does code review":** the Copilot Cloud Agent works with the repository's context*. This means its **reviews aren't generic* — they're grounded in the guidelines, architectural patterns, and conventions the team has defined in the repository itself.

Through instruction files, skills, and rules configurable at the repository level (.github/copilot-instructions.md and custom instructions), you can teach the agent how your Code App is structured, which patterns to follow, which anti-patterns to avoid, and which naming conventions to enforce.

The .github/copilot-instructions.md file is your control point: here you define architectural guidelines, team conventions, and patterns to follow. The agent uses them as a reference for every review and every task you assign to it.

The result is a review that speaks your project's language — not a generic checklist that anyone could copy from a blog post (including this one). If the team has decided that components follow a certain error-handling pattern, the agent knows it — and verifies it.

Final thoughts

The ADO + GitHub setup isn't a compromise: it's a deliberate choice that leverages the strengths of each platform in the domain where it excels. ADO for governance, planning, and the full lifecycle. GitHub for development, AI, and the Copilot Agent's capabilities.

For teams working on Power App Code Apps — and increasingly on Power Pages SPAs too — this configuration reduces the cost of review, improves the quality of the code produced, and maintains the traceability that an enterprise project demands.

The Copilot Cloud Agent doesn't replace the developer: it anticipates problems, handles the more mechanical tasks, and frees up developers' time for the decisions that matter. And that's exactly what you'd ask of a good collaborator.

One frontier I'm actively looking forward to exploring: bringing the same degree of automation to model-driven apps. Today, the code-first nature of Code Apps is what makes the Copilot Agent so effective — but with tools like PACX, App Maker MCP Server, Dataverse MCP Server, Power Platform Skills for Generative Pages, and so on, the prospect of applying a similar AI-driven workflow to model-driven development is becoming increasingly concrete. Watch this space.