Setting up Bitbucket Pipeline for multiple production environments

[mith7]

We are planning to have a Bitbucket Pipeline setup as illustrated below.

Our software is used in critical production facilities, where some customers needs full control of when updates are applied. E.g., when will they get version 1.0, 1.1 and so on.

To solve this, we will merge from a well-tested release branch to a customer branch, whenever a customer wants to upgrade, and let the pipeline do the work of running tests and deploy files.

I’m unsure about this architecture approach.

It this a bad CI/CD design? What disadvantages would it imply?

Any inputs are very appreciated. Thanks.

[mith7]

Anyone?

[mith7]

@Dave Chevell Sorry for "poking" you like this, but may I ask your opinion this? Thanks.

[Michael Hohlfeld]

@mith7 
I work with a similar CD/CI-setup on my side. 

I think you can maybe run into this problem: If you need to deploy a bug fix version (maybe 1.0.1) for a Prod version >>> How you will do it with your setup?

Because this can happen:

In branch "Prod Customer A" version 1.1 is available for your customers.

Your customers run in his Prod-environment your version 1.0

Now you must fix a security issue in version 1.0 and you call it 1.0.1

... and now? Can you offer both versions to your client: version 1.0.1 and 1.1 ? 

[mith7]

Hi Michael. Thanks for input.

Yes I think so, in my setup I will approach it like this:

Each version has a release branch (see yellow box in my illustration above). If a bugfix is needed in version 1.0, we will make a change in release branch 1.0. When deployed we will bump version from e.g., 1.0.0 to 1.0.1. The bugfix will also be made in Development branch if applicable, so the bug is no longer there, when code is merged from development into Test and new release branches (new future versions).

If a bugfix in release branch 1.0 also exist in other release branches, e.g., in release branch 1.1, we will make a similar as we did in 1.0 to release branch 1.1.

If Customer A wants to upgrade to from 1.0.0 to 1.0.1 (to fix the bug he is experiencing), we will merge release branch 1.0 to his customer branch. Customer will now go from having version 1.0.0 to 1.0.1.

If Customer A wants to upgrade to new version, e.g., version 1.1, we will merge release branch 1.1 to his customer branch. Customer will now go from having version 1.0.x to 1.1.y.

[Michael Hohlfeld]

Hi @mith7 

OK. I understand. Sounds good.

Your customer ask you for the update and then you provide this in his Prod-Branch.

I thought the customer can self decide the update from his Prod-Branch. 

[Michael Hohlfeld]

One more question: The test-branch is only one branch... Can this be a problem if you need to test many different test-versions on your test-environment?

[mith7]

Good question. But I think not. The test branch is for testing upcoming features, that will be part of the next version. We do not plan to add features in an released version (only bug fixes and minor improvements). So when a customer wants a new feature, he must upgrade to a new version where that feature exist.