Hi, first time octopus user trying to deploy to Azure. It’s a little confusing if I’m honest
My Azure “environment” is as follows:
Multiple cloud services worldwide in different data centres
Each service is the same but with different configuration (e.g. database connection strings)
Because Azure wipes your guid for normal staging environments in a single cloud service, I have two dedicated cloud services for “Staging” (e.g “000” - West Europe and “001” East US) and different ones for production (“100”, “200”, “300” etc.) each residing in a different data centre. This was the approach recommended by the Azure team so that our test URL is not nuked each time we create a staging environment for testing purposes.
In my head, I see this in Octopus as
An environment for “Staging”
An environment for “Production”
What I want to be able to do is:
One deployment script regardless of the cloud service (it’s the same service after all)
Deploy to each service in turn
Each deployment to each service picks up the different custom configuration for that cloud service deployment and updates the csfg file accordingly
Each octopus environment can support multiple cloud services (E.g. “Staging” = “000” and “001”, Production are the rest.
I don’t know how to do this in Octopus as it appears that each deployment script is specific to a cloud service; therefore the fact that each service is essentially the same, but just residing in a different location is irrelevant - I need a duplicate deployment script that is exactly the same for each cloud service.
This doesn’t sound right as then Octopus doesn’t give me any benefit over doing this management manually? I’d need several different scripts one for each cloud service. which isn’t really that manageable…
Octopus Deploy should be able to do what you’re asking. There shouldn’t be an issue with having several cloud services in an environment which get their own unique configuration.
With regards to deploying to Azure we have an article that goes through the process including configuring the .cscfg files which you can find in the Octopus Docs. Configuration of the differences is done through Variables which you can scope based on machine or environment.
Regards to deploy to each service in turn we also have the concept of Rolling deployments which I think is what you’re after.
Thanks for the reply. Still a little confused - hopefully I can avoid the “multi-tenant” workaround listed elsewhere as it looks like it could get a bit unwieldy.
What I have now is:
Environment = “Staging”
Enviornment = “Production”
Project = “MyApp”. Within this project:
Process = “Azure deployment”. Within this step
cloud service = custom variable (myapp.cloudservice)
I think that would work for a simple swap of cloud service, but my issue is that I have 2 distinct cloud services in Staging and many distinct cloud services in Production, each have different variables that I need to override. I don’t see how Rolling Deployments can help this as they don’t allow me to specify variables for a child step.
Can I use variable scope for this (e.g… have multiple steps, one for each cloud service in production, but the variable scope is set to “production environment; Process step 4: Cloud Service 100” or “production environment; Process step 5: Cloud Service 200”?
I’d rather not have multiple environments, one for each cloud service, which is what is suggested by the multi-tenant deployment pattern.
I think I see what you’re getting at now. Unfortunately Octopus doesn’t yet support multi-tenant deployments in such a way yet. It’s something that we’re planning on addressing in a future release. You can get a sense of our progress so far from the roadmap.
Depending on the number of number of services and the complexity of the deployment process we currently recommend splitting the project up into multiple projects. In case you haven’t seen it we also have an article about Multi-tenant deployments that may be useful. If you do consider this using the Octopus API can make automating setup and deployments easier (In this case you would have to deploy each project individually either manually or via a script).
It’s up to you how you feel best to manage these scenarios. If having multiple steps in a project is easier to maintain than having multiple environments or projects, that is okay and it will work. The only current solution is multiple machines, multiple steps, multiple projects or custom scripts.
We understand this isn’t the optimal solution and I’ve been in a similar situation before myself. While I opted for the solution of a custom script that made individual deployments to avoid multiple projects or environments. I found Octopus was still able to offer me the benefits of distribution, auditing and management.
