How to Deploy Multiple different IIS sites with same packages on 1 sever

Legacy Modelling
1

I have a unique situation here where we have multiple environments for one of our applications, and on top of that also have multiple instances of that environment. I.E.
Development Environment has
Dev1
Dev2
Dev3

All of these IIS websites reside on the same servers, and have the same code, but take you to different instances of the application. They all talk to the same database, but store their data in different folders. I.E.
Dev1 - C:\app\dev1
Dev2 - C:\app\dev2
Dev3 - C:\app\dev3

Now to top things off, not every environment is like this.
Dev has 3 websites
QA has 3
UAT has 3
Performance has 2
Production has 1 website Per server, but has 8 separate servers for load balancing.

Is this possible to setup a proper Lifecycle and Process when the environments do not match?
Could anyone give me some advice on how to set this up?
I thank you in advance for your expertise and help.

2

you could set this up using variable libraries and set per environment Website names i believe , worst case you could setup a couple of tentacles on that machine

3

“you could set this up using variable libraries and set per environment Website names i believe”

This would need to be setup with multiple processes I imagine, or can multiple websites be released in 1 process step?

4

if each of these websites represents an environment you should use the variables approach unless all of the websites are related as components of the same deployment

you can also set variables to the target level which would likely statisfy this case as well

if these are all related to the same deployment you can set up a custom lifecycle with multiple environments per phase

6

Hi Sean,

Thanks for getting in touch! I think a good solution here may be our Tenant feature.

You could create a single project for your application and use one of each environment Dev -> QA -> UAT -> Performance -> Production. From here you can create a Tenant for each different instance of the application on the target server.

Say you have three of the same application you want on the target server: App1, App2, App3

You can create a Tenant for each application and attach your project to this Tenant.

Inside of your project, you can create project variable templates for any configuration values which need to change between the Tenants such as installation directory, connection string, etc.

You can supply values for these inside each Tenant, on a per environment basis. Which gives you good control over which values to use for which instance of the application over any given environment in the Lifecycle.

Deploying the project to three of your Tenants will create three separate deployments using the variables configured above.

Below is a link to our Tenants documentation. I suggest having a look through and decide whether it is for you or not.

Let me know if you have any questions or thoughts on this. :slight_smile:

Best regards,
Daniel

7

I thank everyone for their help and advice on this. I do however still have one issue that I am not sure Tenants handle.

In our current release deployment system (Cruise Control/SVN) we have the ability to choose which branch of code will be deployed to which environment be it qa1,2, or 3.

Now something they like to do here is Test the code separately from each other.
For example QA 1 will receive the code for Bug fix 1, while QA2 will now receive the code for a New wizard, and QA3 will be testing new exceptions and filters.

Each environment had the same base code, but only received a piece of the new code to test alone in it’s environment. Can that be setup within Octopus lifecycle somehow? again I appreciate any help given.

Thank you,
Sean

8

Hi Sean,

Thanks for getting back here. I may need a bit more information to better understand how you are deploying these different bits of code. You mention wanting to deploy different code into different environments. Would these all be packaged independently? (Generally Octopus assumes separate code is packaged independently and we build our features assuming this.)

Assuming they are, you can also take advantage of our Channels feature to make this a bit easier. Whilst Tenants are a great feature for managing multiple instances of the same deployment simultaneously, Channels are great for managing different branches of code. These features can work together to help you to automate your different branches of code over your different instances.

Channels essentially let you set a custom Lifecycle for your deployment and associate different packages to be used in your package steps based of version rules.

As an example, if you have a package with some hotfix code for an application, lets call the package ApplicationA.1.2.3-hotfix

You are able to create a Channel called Hotfix and define a Lifecycle of your choice for this Channel. Say a new Lifecycle with only the QA 1 Environment.

Inside this new Hotfix Channel, you can create a version rule and associate it with a package deployment step. Lets say you define the version rule for this Channel as -hotfix. When we create a release to the Hotfix Channel, Octopus will automatically know that you want the latest package with the -hotfix pre-release tag to be used for whichever step you have defined when creating the version rule. Since the Hotfix Channel only deploys to QA 1, we don’t have to worry about QA 2 & QA 3 getting the hotfix code.

This can easily be used in conjunction with Tenants to deploy multiple instances of different code branches with a single deployment.

I hope I have made sense here, Channels and Tenants can take a bit to wrap your head around sometimes, but are very powerful features inside Octopus.

If you have any questions at all here, or feel that I have not really answered your question, please let me know. :slight_smile:

Best regards,
Daniel

9

ok so here is an example more specific that we need.

We have websites for Dev that work Independently of each other. Our Company considers this the same environment as it is Dev1 & Dev2. Though they have their Application settings and Website Configurations all saved on one server Dev-Webserver but in different Locations.
I.E.
Dev-Webserver hosts the files for
C:\App1 - is associated with IIS Website - App1 - Connect to DB DevSql01\dev1
C:\App2 - is associated with IIS Website - App2 - Connect to DB DevSql01\dev2

Now we have the same in QA
QA-Webserver hosts the files for
C:\App1 - is associated with IIS Website - App1 - Connect to DB QASql01\qa1
C:\App2 - is associated with IIS Website - App2 - Connect to DB QASql01\qa2

Is there a way to do this with Tenants? It seems trying to differentiate where to send certain things is troublesome.

For instance, Tenants are able to associate themselves with Machines, and will run in certain environments. I have not found a way however to add them into Variables.
So a process that calls the DB from the Smoke environment gets multiple variables if you associate the tenants to the machines…
DevSql01 - Is part of Smoke Environment - Part of Tenant_Dev1
DevSql01 - Is Part of Smoke environment - Part of Tenant_Dev2

The issue seems to be during the Process steps I can’t say when i choose tenant_dev1 only send to Tenant_Dev1 unless I make a new process for Every single Tenant.

I would prefer not to have a Ton of environments if thats possible
I would like to stick with Smoke-QA-Test-Prod, but for us its more like this
Smoke (Dev1 & Dev2) - Both instances are on same servers, different file locations and IP’s
QA (Qa1, QA2, QA3, Performance) all 4 instances are on same servers, different file locations and IP’s
UAT (UAT1, UAT2, UAT3, Training) all 4 instances are on same servers, different file locations and IP’s
PROD (PROD1, PROD2, PROD3, PROD4) - All of our Prod instances are on different servers.

10

Hi Sean,

Thanks for getting back. I think this is still exactly what Tenants has to offer. Perhaps I can provide you with some more examples relating to what you are trying to achieve.

You mention the desire to keep your environment simple. Smoke -> QA -> Test -> Prod.

Lets assume you create those four environments and we can build up from that.

Say you have three applications built and ready to go, lets call them App1 - App2 - App3.

Now, lets assume you have 4 different customers receiving these applications, and you need them to be hosted in separate directories with separate configurations. They will still need to be promoted through your four environments but remain individually customised for each customer(Tenant).

Using Tenants here, I would create a single Tenant for each instance of the application, or Customer, however you look at it. Tenants is more just the label we use to represent the instancing of a single project/application on the same target.

Say I have four customers, named Tenant-A - Tenant-B - Tenant-C - Tenant-D.

So I create a single Tenant for each of my customers. After I create my Tenants, I connect them to each project that those Tenants will receive and define each Environment that application will be able to be deployed to. For the simplicity of my example, lets assume each Tenant will receive all three of our apps and be deployed to each Environment.

Now, I want to implement some configuration changes which will need to be different for each Tenant and different again depending on which Environment they will be deploying to.

Lets start with App1.

Inside of the project App1 I will create a Variable -> Project Templates. This is called a Project Variable Template. This is essentially a Tenant Specific Variable.

So I need to be able to connect to a unique SQL Database for each Tenant and Each environment. I can set this up here by defining how the variable will look. Give it a name, some helpful information to identify what it is for and assign a variable type. I assume just a single line text box where I can put in a connection string for my Database.

Once that variable is created and saved, and assuming this application is connected to the Tenant, you can open the Tenant and browse the Variables tab from within the Tenant.

This section is where you are able to define a value for your connection string variable you created. You have the option to enter a different value for each Environment in the Project’s Lifecycle.

Now assuming you do this for each variable you need defined between your Tenants, you can have a single project where you only need to reference these variables once. Deploying App1 to all four Tenants into the Smoketest environment will reference the connection string value on a per-Tenant and per-Environment basis.

Creating four different deployment tasks which will deploy App1 separately and dynamically to each Tenant.

I’m sorry this explanation turned out to be so long. And I really hope it addresses your questions on how to achieve what you are after here. I strongly suggest you carefully read through our Tenants documentation as it has a wealth of information and examples on how you can use Tenants to achieve the setup in your example.

If I have missed something here or you have any questions at all, please do not hesitate to let me know.

Best regards,
Daniel

11

I believe I understand what you are explaining in my forum question. I don’t think I am explaining it as well as I could.
When I said App1, App2, App3 … these are all the same app, coming from the same project, they just need to each have their own individual deploy button. I created tenants for each Instance of the Application. For this example we will call the application “Test”
I need the ability to push Test v1.4 to any tenant I want by itself. Right now, it seems our setup has process steps that call for Environment, but because the Tenants are both of the same environment (Dev1 & Dev2 tenants are both a part of the smoke environment) it seems the Process will find all machines associated with Smoke and push out… so even though I am clicking Env - Smoke, Tenant - Dev1, it will still push to ALL Smoke environments.
Our Variables are setup in such a way that it decides which Directory to load the files to, but since both of these Tenants are Smoke it now sees 2 environments. The Variables are defined in One Library Set called “Test Variables”
Would we want different variable sets for Each tenant? And if we did want that, how do we let the 1 Project know how to select the proper Variables for that Tenant?
If it makes it easier you can email me at Sedler@Clayton.com for faster response times. I 100% appreciate your help as this is a large project we are trying to move from CruiseControl/SVN and I am trying to convince them that Octopus/bitbucket/git is the way to the future.
It’s possible I am just having trouble correlating the Tenants into this 1 project properly, or maybe we need to redo the way the variables are currently set, as they are set to the Project right now and are NOT set to each tenant. If we did do each tenant variable I am still confused on how the Project will know to call that specific tenants variables right now.
Thanks again,
~Sean Edler~

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.