CODEWITHSUNDEEP
continuous-integrationazure-devopsversioncontinuous-deploymentsemantic-versioning
René Schindhelm
René Schindhelm

Reputation: 2507

General question on semantic versioning releases using CI / CD pipeline

I have yet to find clear guidance on semantically versioning software releases using Azure DevOps (Server) CI/CD.

My basic understanding is that I would set up a CI pipeline for our team so that we get the benefits of build failure notifications, test execution, code coverage, static code analysis and even more goodies.

The CD pipeline picks up on the CI pipeline, rolling out the artifacts on the different environments upon their completion.

Using this approach seems to not make sense to me. What about builds that fail because a dev didn't pay attention or that the team wants to discard? Such builds won't find their way into production but might use up version numbers, leading to gaps in our versioning scheme.

What is your experience or approach for semantically versioning software releases using CI/CD pipelines? Do you cherry-pick builds? Do you have a separate build pipeline for building releases?

Upvotes: 1

Views: 1288

Answers (1)

Daniel Mann
Daniel Mann

Reputation: 59035

  1. Builds that fail don't get deployed. For builds that succeed but fail QA or integration testing when deployed to lower environments, you can put approval gates so that someone has to approve the release before it proceeds to higher environments.

  2. If you build version 1.0.1 of your application and deploy it to dev and it's no good, that doesn't mean that version 1.0.1 doesn't exist. It exists. It was comprised of specific code assets. It was bad, and your users will never see it, but that's fine. If the users see version 1.0.1 jump to 1.0.94, why does it matter?

Upvotes: 3

Related Questions