Source Control & Collaboration – Git Good or Get Ready to Rebuild

At this point in Nevermore Technology’s ALM saga, we’ve covered environments, pipelines, and solutions. But now we’re stepping into one of the more controversial topics—source control.

To the pro devs, it’s standard practice. To the citizen developers? It’s the thing that makes Power Platform feel like “a proper job.” And to everyone in between, it’s a blessing and a burden.

Why Source Control?

Let’s spell it out: without source control, you’ve got no history, no traceability, and no guarantee that the version you’re deploying is the one you think it is.

Nevermore learned early on that managing 90+ apps across five Dynamics instances without source control was like trying to keep a lid on a boiling pot—with your hands.

So they did the sensible thing: they introduced Git.

What Gets Tracked?

Everything that moves through Nevermore’s ALM pipeline passes through source control, including:

• Solution .zip files (exported via pipelines)
• Extracted solution contents using Power Platform CLI
• Canvas app .msapp files (stored in folders with clear naming)
• Documentation (release notes, ownership records)
• Environment variable schemas and references

Branching Strategy: Simple, but Sensible

Nevermore uses a trunk-based branching strategy, with branches for each app or functional unit:

• main – always stable, production-ready
• dev-appname – where feature work happens
• release-appname – when a feature is ready to promote

No 19-level nested branches. No experimental mark-testing-v3-mergeplease branches sitting abandoned for six months.

They also enforce pull requests (PRs), because:

• It forces code review
• It adds accountability
• And it stops that one person from pushing broken stuff straight to main

Collaboration: Pro Devs + Makers = Success (Eventually)

Nevermore doesn’t separate pro devs and citizen makers—they pair them.

• Makers build in Power Apps Studio
• Devs help set up structure, reusability, and logic improvements
• Both parties commit changes to the same repo, through pipelines or CLI tooling

Sometimes, it takes a few awkward calls to explain what a “merge conflict” is. But once the process is understood, it creates far better outcomes:

• Apps that are easier to maintain
• Shared understanding of what’s changing and why
• Less duplication of effort

Tooling: Pick What Works

Nevermore uses Azure DevOps for work item tracking and pipelines, and GitHub for code storage. Why both? Because different teams prefer different tools, and they’ve integrated them using service connections and webhook triggers.

Key tools include:

• Power Platform CLI
• Microsoft Power Platform Build Tools for Azure DevOps
• Pac CLI Extensions
• Visual Studio Code for inspecting extracted solution files

Real Talk: The Git Learning Curve

Not everyone takes to Git straight away. One of Nevermore’s early hiccups? A developer overwrote a working app by pushing an old .msapp file into the repo. That led to a full rollback, some tense stand-ups, and an updated contribution guide.

Now, every maker gets:

• A walkthrough of how solution extraction works
• Training on Git basics (clone, commit, pull, push)
• Access to a test repo to break things safely

Because source control isn’t just about protection. It’s about confidence.

TL;DR – If It’s Not in Git, It Doesn’t Exist

Source control is the glue that binds Nevermore’s ALM together. With Git at the centre:

• Deployments are consistent
• History is preserved
• Collaboration is structured
• Recovery is possible

You don’t need to be a DevOps ninja to benefit. You just need a process—and a team willing to learn it.

Coming Up: Blog 8 – Dependency Hell and How Nevermore Avoids It

In the next blog, we’ll dive into dependencies—what causes them, why they sneak into solutions, and how Nevermore avoids circular pain by managing solution composition like pros.

Expect plugins, flows, lookups, and maybe a war story or two.