2

We would like to try building a release pipeline for our product in VSTS - however, our product requires a separate instance of the application per customer (there are some legacy in the picture here :)). What we THINK we want, is a process like this:

For each customer:

  • Update DB schema
  • Configure a container, with customer-specific configuration etc.
  • Publish the container into Azure Container Registry
  • Deploy the container in Azure Container Service (OR on-prem if the customer runs on-prem)

The configuration can be multiple things: Extensions of the API in the application (new DLLs basically), connection strings, ...

I figure we can do this fairly easily using a custom PowerShell script, but I would like to not write anything custom (at least for the "looping" issue) if I don't have to. We could also create separate environments in VSTS for each customer, but that seems quite unmaintainable with well over 100 customers.

Some additional details: - There's a separate DB per customer - There's two separate web applications per customer

So what's the best practice here? Any advice? Thanks! :-)

Our thoughts on how we want to deploy our application in the future

Improve this question
5
  • Where is the picture you mentioned? And What's the project type do you want to deploy in VSTS and what's your definition now? Commented Mar 21, 2018 at 5:29
  • Sorry - that was more a figure of speech from my end, not an actual picture. We are still in the planning phase on how we shall roll this out - our application is an enterprise application (originally on-prem), today it has a rather heavy installation program that must be run. Our plan is to work on packaging it as a container, in order to simplify deployment and take steps towards CD. We currently do not have a release definition for this. This is what we are going to build however. Please let me know if this didn't answer the question... Commented Mar 21, 2018 at 7:38
  • I have updated the post with a diagram of what we are thinking of, and some additional details. Commented Mar 21, 2018 at 7:45
  • You can refer related links (learn.microsoft.com/en-us/vsts/build-release/apps/cd/… and learn.microsoft.com/en-us/vsts/build-release/apps/cd/azure/…) to config your release definition. Commented Mar 21, 2018 at 8:50
  • Thanks - but doing the actual deployment is not the issue here. That we'll figure out easily. My question was rather how to actually create and deploy customer-specific images, when we have hundreds of customers. Mostly it was a question about best practice/if there's anything built-in to TFS/VSTS that allows us to manage this, or if we have to resort to a custom powershell for iterating through each customer and deploying. Commented Mar 21, 2018 at 10:23

1 Answer 1

Reset to default
1

You could think of doing it in two ways.

1 - By creating one environment for each customer. So you could have the exact same tasks for each environment, or have the flexibility to change steps in a particular environment.

This approach would give you also the ability to use a flow pipeline, because your build will be released only after is passes your internal QA and other processes.

To do it easily, you could also create task groups to reuse then in each environment.

2 - The other way is to create create separate releases for each customer or group of customers. This will also give you the same flexibility, you can use your builds, but you have to add some extra steps to make sure you are using the right build, since you can choose any build when you create a release, which you can do mannualy.

Updated

A third option could be to create on environment for all customers and then have the one deployment agent installed for every customer, using all of them on the same deployment group. Then have one file with all your variables per customer, with the file named with the agent name, and a powershell script that uses the agent name variable to find what file to run. This powershell script would then run all your individual configurations.

In that case, I suspect that you would end up doing almost all your deployment in powershell, which could be more time consuming for you to maintain. You also have to keep in mind that in this particular scenario you would update all your customers the same time, because all agents would be on the same deployment group.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

So I guess there's no "built-in" functionality to handle such a scenario. Kind of what I suspected. We'll have to see which approach fits best. Thanks!
Unfortunately there is not. I'm facing the exact same scenario as yours. We have implemented both scenarios. And we have onprem customers as well. So for more complex deployment cenarios we are using a separate release.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.