devops - Uniquely identifying staging releases and understanding CI/CD pipeline

Question

I am trying to create the following CI/CD pipeline for a sbt project, although the idea is agnostic of any language:

main <-(A)- staging <-(B)- develop <-(C)- features/feature-x

Here, A, B, C identifies following workflows:

Workflow C: Idea of this workflow is to be able to continuously merge fixes/features to the develop branch.

• perform unit/integration tests
• get code reviewed by code owners
• publish artifacts to the snapshot OSSRH

Workflow B: When there are enough fixes/features in the develop branch, code-owners could decide to merge this branch to staging branch

• perform unit/integration tests
• push artifacts to staging server

Note: Here QA comes in to test the staging release.

Workflow A: When a staging release has passed all QA tests, it will be released for public

• perform unit/integration tests
• release staging artifacts
• publish release notes

I have couple of questions related to this pipeline:

1. Let's say staging release is identified as v1.2.0. Now QA finds a couple of issues in this staging release and the development team fixes and republished the staging release. My question is if we continue to keep the same version, how could we identify if we have a newer staging release? (I had been referring to the Sonatype docs to release to snapshot/staging repo) One way I could think of to uniquely identify newer publishes is by using commit id but that doesn't look intuitive or we could bump up the version number but that wouldn't be correct wither. Another way I could think of is using pre-release prefixes like "-RC" but even these are meant for public releases. See here.

2. How would this pipeline look like when we have to support multiple releases? Let's say, we have made public releases 1.2.0, 1.3.1 and 2.3.1. In this case, we may have to support all the releases such as 1.2.x, 1.3.x and 2.3.x independently.

Would it look like this?

main1.2.x <-(A)- staging1.2.x <-(B)- develop1.2.x <-(C)- features/feature-x

main1.3.x <-(A)- staging1.3.x <-(B)- develop1.3.x <-(C)- features/feature-x

main2.3.x <-(A)- staging2.3.x <-(B)- develop2.3.x <-(C)- features/feature-x

• How would we deal with merging changes from say 1.2.x to 2.3.x and so on?
• Won't this may cause merge conflicts every time we may merge?
• There could be chances we won't want to merge those changes to newer branches, right?

Anything you would like to suggest to improve this pipeline?? Could you point to documents/books that discusses and explains cicd pipeline and release versioning in depth?

标签： devopsgithub-actionsnexussonatypecicd