Is SemVer redundant for continuous delivery?

Question

We are developing distributed system with continuous delivery.

Releases are being scheduled, tagged with non-technical marketing version names. Each release aggregates set of changed components with desired features, verified by integration testing pipeline. We aren't deploying continuously to production, but we do deploy continuously to test environment for release candidates integration testing.

System components are frontend, backend, adapter module and a shared database. They are packaged as docker containers. We use Docker registry as an artifact repository and docker compose to integrate the latest versions of each component for integration testing. See the following DAG diagram for pipelines and their dependencies. Basically change in the upstream project triggers a rebuild of each downstream project, until leaf nodes are reached. Integration testing is triggered, when leaf node docker image is pushed to registry. Trigger logic is codified in the registry webhooks.

Obviously components needs some technical version to associate production releases to particular builds of components for tracing and reproducing purposes. Currently, each master build is tagged with a semantic version. But is using SemVer and git tagging redundant in this case? Can we use just git hashes and build numbers instead? I don't see any additional value from using semantic versioning in this case. Automated changelog is a requirement.

Also, what is the best way include actual version number in docker container started with the latest tag by integration testing pipeline? Ideally, from integration pipeline results I would like to see actual component versions used for successful test run.

I would like to also hear, if this solution contains any anti-pattern or sub-optimal design.

Answer 1

Is SemVer redundant for continuous delivery?

Short answer is, maybe, but probably no, it's not. IMO, you are not asking the right question.

When the question is:

Is SemVer needed for internal publication and consumption?

The answer is an emphatic no. The scenario you described can be implemented with build numbers and Git commit Ids. The only time you really need SemVer, is for communicating risk to consumers. In your scenario, you are both the publisher and the consumer, and your consumer's sole purpose is to verify or determine the quality of a candidate build.

You might want to read some of my other rants, wrt maintaining package or other output version information in the repo:

https://stackoverflow.com/a/66910767/3150445 How does CI affect semantic versioning?

At some point, you may determine that you have a build product worthy of release. If your consumers have a choice of taking that release (pull-mode), then you should probably use SemVer to version that final output. If they don't have a choice, such as when you publish a web application and the client side code that goes with it, then you can probably continue to get by without SemVer. All your dev's and admins need to know is, the provenance of the bits, and what version or range of them should still be in production. You're basically in a push mode.