This is my team’s first attempt at deploying Azure WebApp’s from a tenanted project. The biggest issue so far is deploying to more than one Tenant at a time. Our scenario is kind of complicated, so don’t hesitate to ask for clarifications.
Each tenant has its specific region. The project is deploying an Azure WebApp to four different regions. We use the integrated “Deploy an Azure WebApp” step template to deploy the WebApp to Azure, which requires WebApp Targets. These targets are created as part of the deployment process. Because it’s impossible to run this step on behalf of a deployment target’s name set as a variable, we must use the same tag to deploy to different tenants.
Having to hardcode the “target role” limits our ability to deploy more than one tenant at the same time, because a target deploys one WebApp and we have only one target. Using multiple targets with the same target role might trigger a deployment for other tenants WebApp’s and we do not want that.
Thanks for getting in touch, and I appreciate the level of detail! The way I think I’m understanding your situation is based on some assumptions so please correct me if so and elaborate where needed.
In addition to your region-specific tenants, you’re after customer-specific tenants (essentially multi-tenanted within the region), and the way you’re looking to achieve that is to use a dynamic target role (via a variable)? This would be to accomplish the scenario “I want to deploy to Customer A in Region A and Region B, but I want to deploy to Customer B in Region B only.” Is that accurate?
To approach this kind of scenario, usually what’s done is a bit different, and that is to use environments for the region. In your case that’d look something like Development, Development - US, QA, QA - US, QA - UK, then 5 Production environments (Production, Production - AU, and so on).
And just in case it helps in some way, I’ll point out that you can create multiple targets with the same role, since the targets can be scoped to individual tenants (image below). Also when starting a tenanted deployment, one deployment is created for each tenant.
Thanks for your response! Let me explain our environment in more details:
We used to configure projects with multiple environments, one per region. For example: dev us, qa us, qa uk, prod us, prod uk. This setup was simpler to configure but the resulting project overview had a scrollbar and was harder to navigate through. While researching on other options for similar workflow, I saw this example from the Octopus documentation and thought adopting it. This worked perfectly for deploying a few projects, but none of these were using WebApp’s.
The main obstacle with WebApp’s deployments is the target. As we have a lot of projects, we try to automate everything, even setting-up the target and deleting it after the deployment. However, the problem with targets is its hardcoded tag. By deploying only one tenanted environment at a time (ex. prod us), the target gets created, deployed, then deleted. When deploying two or more tenanted environments at a time (ex. prod us + prod uk), there’s a race condition between which deployment will create the target last, resulting in the settings of the target being overwritten.
For that, I see a few solutions, but they aren’t optimal:
Create one target per environment per tenant. Each target is named differently and uses a different tag. And as we cannot dynamically change the target’s tag name in the “Deploy an Azure WebApp” step template, we’d need to clone this step template by the number of tenants.
Do not use the “Deploy an Azure WebApp” step template. Instead, write and maintain a homemade script for the matter, which suppresses the need to use targets. However, here, we’d be duplicating a functionality of Octopus and would need to maintain this script.
Be able to set the target tag as a variable, which would allow us to create multiple targets with unique tags within the same process step. This is not currently possible in the latest Octopus server version.
Thanks for following up! I appreciate the additional details. I’m wondering if a couple more thoughts might help in this case (again please let me know what you think). Could you:
Use tenant-scoping on the target (screenshot above) so as to avoid the “dynamic-role” limitation?
Define a run condition on the step that creates the target so as to skip it if the target already exists, avoiding the race condition?
From your recommendations, the project’s deployment process now creates one target per tenant, with an unique name but using the same tag. And because these targets are scoped to a single tenant, only one WebApp (matching the tenant) is deployed, which is what I need!
Maybe I’m not explaining it right but it works perfectly fine for our use-case
That’s great to hear you have a nice solution for your scenario! I appreciate you letting me know, and if you have any questions or concerns in the future please don’t hesitate to reach out.
