Auto-incrementing solution version numbers in pipelines

Every deployed solution should carry a unique, ordered version number. It’s how you tell at a glance which build is running where, and it’s what makes rollbacks and support conversations straightforward. The trouble with doing it manually is that it’s easy to forget — and a repeated version number causes confusion at exactly the moment you least want it, in the middle of diagnosing a production issue.

The fix is small and worth doing early: let the pipeline set the version automatically on every build.

Why version numbers earn their keep

A version number is more than a formality. It gives you:

• Traceability — a clear line from a version deployed in an environment back to the exact build, and through it the commit, that produced it.
• Confidence in rollbacks — because each artifact is uniquely versioned, going back to a known-good build is unambiguous.
• Clear support conversations — “which version are you on?” becomes a question with a precise answer.

When two builds share a version, all of that breaks down. You can no longer be sure which one is actually deployed, and that uncertainty is corrosive precisely when you need certainty most.

Let the pipeline do it

A short PowerShell step in the Azure DevOps build pipeline can increment the version automatically on every run. Conceptually it does three things:

1. Read the current version from the solution.
2. Bump a component of it — typically the build or revision number.
3. Write it back before the solution is packed.

A common convention is to tie the version to the pipeline’s own build number, so the mapping between a version and a build is automatic:

$build = "$(Build.BuildId)"
# read the solution version, replace the revision with $build,
# and write it back before packing the solution

From then on, no one has to remember, and no two artifacts ever share a number.

Choosing what to bump

Solution versions have four parts — major, minor, build and revision. A simple, effective policy is to manage major and minor deliberately by hand (they signal meaningful change), and let the pipeline own the build/revision automatically on every run. That way human-meaningful versioning stays intentional, while the machine handles the uniqueness that humans forget.

Consistency you can rely on

Because the version is set as part of the build, it’s tied directly to the pipeline run and, through it, to the commit that produced it. That gives you a clean, automatic line from a version in an environment back to the exact change that created it — which is precisely what you want when you’re diagnosing an issue or planning a rollback.

It also removes an entire category of human error. Nobody has to remember to bump the number, nobody accidentally ships the same version twice, and the version in production always means something.

A small automation, a real payoff

This is about as small as pipeline automation gets — a handful of lines of PowerShell — but it removes a recurring source of avoidable confusion and makes the whole release process feel more trustworthy. Like a lot of good DevOps practice, its value isn’t in doing something clever; it’s in reliably doing something simple that humans otherwise get wrong just often enough to hurt.