Hey what is the process to deploy a package to multiple sites for a single environment? With the azure web machines this made sense as you would just have multiple web app machines in a single environment.
We also typically have our production sites in a separate subscription. I can see I can do a custom binding, but then I have to have a variable for the account id? which seems to not be very human friendly?
Cheers,
Luke
Hi Luke,
There are two ways to achieve this:
Personally, I prefer the second option. Have an environment for each Azure Web App (possibly the same package to different regions?). If you name your environments and sites appropriately, in the step you can use something like AcmeOnline-#{Octopus.Environment.Name} in the Web Site field.
Regarding accounts, it is the same answer. You can either have multiple steps (each configured with a different account), or use environments and variable binding.
For convenience, you can then create a lifecycle for your project that will allow you to deploy to all those environments at once.
I do understand that for your scenario, the 3.0 method (with Azure targets) seems more elegant.
A bit of background:
We had many discussions internally regarding this. Our dilemma was that there are two distinct ways that people manage their Azure environments. There are those (and from your question I’m assuming you’re more in this category) that have known ‘targets’ that they deploy to repeatedly. Then there are those that dynamically create and destroy their targets regularly. In the long-term, we don’t want two distinct ways of managing Azure environments in Octopus (because it’s confusing to users and more complex to maintain). And the 3.0 way was unusable for those in the ‘dynamic’ group. The 3.1 way is more powerful, and supports both usage modes.
I hope that helps. If we can be of any further assistance, you know where to find us.
Regards,
Michael
So if I had two sites in a single environment,
i.e. production has the primary and a secondary for DR.
Do I then need to use multiple steps to deploy to both? or can I set an array of values and it will process the step multiple times for each set of variables? akin to how we can have multiple machines of the same role in an environment.
Oh and for accounts can I reference them by name or do I need to use the id of an account? Which makes it harder to recognise in the variables.
Hi Luke,
No, you can’t use an array of sites.
I would still probably create an environment for each site (e.g. Production, DR). This means you would have to deploy your release to both environments.
Again, you could leverage Lifecycles: You could have both your DR and Production environments in the same lifecycle phase, and set them to deploy automatically when that phase is reached. This works if your previous phase is, for example, a staging environment, and there is a manual step to sign-off on the production release. Once that step is approved, the Production and DR environments would both be automatically deployed.
That’s just an example of one way to set it up.
Regarding accounts, it is the ID not the name (in case you change the name).
But the ID’s are somewhat human-friendly. For example, if your account was named (originally) foo, your ID will be azuresubscription-foo.
I’m trying to figure this out too. We currently have two logical environments: Dev, Production. I’ve just added a second Azure Web App in a new region that will be used by Azure’s load-balancer. My site should be deployed to both regions at the same time. It feels a bit strange to create a new environment in this situation.
I actually think being allowed to provide an array of site names in the Azure Web App step is the cleanest way to go with this setup since everything else is identical. For now I’ll probably just duplicate the step and set it to only run in the Production environment.
Hi Brian,
Thanks for the feedback.
We are currently bouncing around some ideas to make this scenario nicer. For now, your solution should work just fine.
Regards,
Michael
@Michael, This is something we need sorely as well, we have multiple web apps in a redundant manner in multiple azure regions. The environment approach in 3.0 allowed us to just use roles for this :(. If we could pass a comma separated list of webapp names (or an array or whatever), or somehow do something similar to the 3.0 version of adding a webapp definition to a role that would solve this problem.
Ed (actually, everyone on this thread),
If you have a few spare minutes, take a look at our recent post on the solution we are proposing for multi-tenancy (https://octopus.com/blog/rfc-multitenancy). In particular, we believe the idea of environment tags may fit this scenario. Basically, this would allow you to create one environment per Azure location, but then tag them all as, say, ‘Production’, and treat them similarly. e.g. deploy to them all together.
We’d be interested to hear your thoughts on this.
Luke, Brian, Ed (and anyone else interested in this issue),
We would love your opinions on a feature we are proposing: Cloud Region targets.
We are hoping this new target type may provide a solution for the issue discussed in this thread. Your comments on the blog post would be most welcome!
It feels mostly there, but I’m not sure. My initial reaction is that is a little janky, but that may just be me starting to process it through.
I replied over on the Cloud Regions Blog link above in Disquss, but just for completeness, thought it might be worth repeating here:
We are a new Octopus Enterprise License customer and we have an almost identical need to Jason’s .
Our environment is as follows:
All Azure
2 Environments (UAT & PROD) with potentially another testing environment to come online for performance and automated regression testing
6 Regions per environment (for UAT and PROD anyway)
Multiple Cloud Services (worker/web roles) and Web App projects
We’re currently using a mix of TeamCity driven Powershell scripts and manual steps and are trying to move to a mature process with Octopus, but given our topology, it’s clearly no small task to get started, especially considering the 6 regions.
Since we have yet to build out our OD configuration, we’d love to know a bit more about the Cloud Regions and when a build with support for them will be available for us to try.
Any guidance you can offer in terms of short term and beyond would be greatly appreciated.
Matt,
I believe the Cloud Region targets will be ideal for your scenario. Obviously the only drawback is they aren’t currently available. They will be in our next minor release (3.4), which is at least a month away from full release. They will be available in the next alpha\beta release if would like to have a play; keep an eye on the blog or Twitter for notification.
My suggestion for an intermediate solution:
Create your environments (UAT and PROD). Create your projects containing your cloud-service and web-app steps, and duplicate those steps per region. i.e. one Azure step per region.
This won’t be as nice as having the cloud-regions. The main drawbacks will be:
Then once 3.4 is released, your migration process will be to create your cloud-region targets and remove the duplicate Azure steps.
I hope this helps. Don’t hesistate to ask if there’s anything else we can do to help.