What's the best way to approach this deployment scenario?

Legacy Modelling
1

Here’s our situation:
We have an application that uses a plugin architecture. When we deploy to our daily environment, we need to update 4 different websites with the same code, on the same machine

  • Default Web Site
    • AppWithPlugin1
    • AppWithPlugin2
    • AppWithPlugin3
    • AppWithPlugin4

In addition, a service is installed for each version of the application on a second server - this is due to a machine-specific licensed application dependency. So that server looks like this:

  • Default Web Site
    • AppServiceForPlugin1
    • AppServiceForPlugin2
    • AppServiceForPlugin3
    • AppServiceForPlugin4

The way I’ve gotten it working now is to duplicate the deployment target on the two servers 4 times - so basically each plugin has its own target, but it’s really the same tentacle.
I’ve gotten things broken down with variables for #{Plugin} and #{Environment} (Daily, Automation, etc) which I have defined for each unique combination.

So this works, but it feels like I’m missing something obvious to handle this situation better. For our purposes, there’s no order to which plugin should get installed first - ideally they would all get deployed at the same time. The way this works with the duplicate deployment targets is that they fight for the one tentacle, and I’m sure it takes longer than it should.

Any thoughts on how to make this better? The next step in the lifecycle is to deploy to the automation environment, which has a similar setup.

Thanks in advance,
Mike

2

Hi Mike,

Thanks for getting in touch. I don’t think you are missing anything. Deploying four websites and four services is going to take some time no matter how you configure it, and the way you have chosen seems reasonable.

You can use the OctopusByPassDeploymentMutex variable (https://octopus.com/docs/how-to/run-multiple-processes-on-a-tentacle-simultaneously) to force deployments to run in parallel even on the same machine, but this will almost certainly cause intermittent problems when dealing with IIS (the parallel steps will all be trying to edit the IIS applicationhost.config file at the same time, which often causes problems).

Another approach would be to make a step template, and provide the #{Plugin} value as an input to the template. And then put that template into a single project multiple times. That probably better models what you are actually doing (that is, for each deployment you want to deploy four websites to a single machine). But that isn’t going to get around not being able to run deployments to the same machine in parallel without possibly running into problems.

Regards,
Mark

3

Hi - thanks for the reply. I’ll take a look at that variable and see how it changes things.

What about multiple installs of the tentacle on that server? Tenants?

4

Hi,

You shouldn’t need to install the Tentacle.exe multiple times, you can achieve the same thing by setting up multiple “Deployment targets” (https://octopus.com/docs/deployment-targets) in Octopus pointing to a single Tentacle.exe install on that server. And that will work fine. They will be treated as separate targets by Octopus.

So you have three alternatives:

  1. Just duplicate the deploy step four times, once for each plugin.
  2. Have four Deployment Targets on the target server and have a single deploy step targeting all four targets, using variables to scope the plugin to each Deployment Target.
  3. Have a tenant for each plugin, with all tenants pointed to the same Deployment Target, use variables to scope the plugin to each Tenant

None of these get around that we prevent deployments running in parallel on a single server. The first is the simplest, as you go down the list you add more complexity, but possibly have more configuration options available to you. I’d probably stick with 1. until I ran into problems with it, but 2. certainly reduces some repetition of setup. Tenants are a very powerful feature, but add quite a bit of complexity that I don’t think you need.

Regards,
Mark