Pipeline fork - multiple customers

We have a product that are shipped to a couple of customers.

We currently have a standard Build → Test → Preproduction → Production pipeline.

But each customer typically has different maintenance windows. This means we can't ship to all the customers at the same time in the production stage. Instead, we copy the build to a seperate server, where we execute the deployment scripts manually later.

What we want is for the production stage to be able to fork to each customer, in order to have an approval gate for each customer before the customer specific plan is executed.

What are the best practise for this use case? Do we need to have a seperat application per customer to be able to control the deployment from Buildmaster?

Product: BuildMaster
Version: 5.8.1

jstarbird_7831

I have a similar situation.
For us we setup a db that I query from the executing plan to establish which customers can be upgraded/installed during a deployment per server in a role within the environment/stage.
What this doesn't solve for us is being able to automate that fully. We can for the first time it is deployed but subsequent runs have to be started manually. At least until BuildMaster will allow you to schedule a Re-Deployment to a Stage via UI or via API calls.

We then handle the approvals via a front-end to that db.

Another possible solution for you, you can create multiple Stages all within the one Environment. So you could have a Customer1 Stage, Customer2 Stage, etc. Each with their own approval rules, deployment Windows, pipeline variables, etc. This method really depends on how many customers you need to do this for, to many and your Pipeline will be a bit cumbersome.

Thanks Jon! This is not an uncommon pattern, it's something I call the "quasi-custom software" problem. I.e. you have a "small" number of customers (dozens not thousands), and each customer gets (1) small customizations to a common platform, and/or (2) customer-driven testing and rollout scheduling.

In BuildMaster, I have seem both patterns; the "customer per app" seems to work the best when you need individual workflows and customizations, and then you can just deploy artifacts from the "core" app.

Having seen this problem for many years, I have yet to see any tool that will "properly" model the situation; Octopus does have an interesting "multi-tenant" feature, but it's not so well suited for individual maintenance workflows. In my mind, this is a key benefit to the "quasi-custom software" model that companies like yours provide.

That said, I think we will have definitely have better handling for this in our next generation of tooling (i.e. Hedgehog).

Projects will lend better to sharing than applications, and one of our usecase for nested projects will be grouping customers in this manner
Universal/romp packages will be able to be bundled, allowing for an easy conceptualization of the "quasi-custom" code as well

It's not a huge departure from BuildMaster now, but it will just be much easier to handle I think!