I’ve started the trial of Octopus Deploy, to see if it could help where I work.
At the moment we have a very manual process of;
Either use existing binaries, or build and publish the new ones if it’s a new version of the software.
Zip them up and copy to the relevant server (Sites and Services are included in this - Windows platform)
Configure IIS - 10 sites in total.
Configure Services - 2.
Re-configure all of the .config files for the 10 sites and 2 services.
Configure ADFS services for single sign on.
We could cut a phenomenal amount of time down by automating some of this, it’s all entirely manual at the moment.
I’m sort of stuck at the first hurdle however.
I’ve started off by just aiming to at least get IIS sorted by Octopus Deploy.
So I’m building the Steps Within my project, and it seems to be specific to one instance, is that right?
So if I wanted to run the same process again, but for a customer with a different name, I’d essentially be modifying the steps a lot.
I suppose in my mind I was expecting it to ask me - What’s the name? and then it goes and replaces all of the name parts in the IIS configuration steps with that name.
In addition to that, the ‘package’ I uploaded, contained the published sites.
Am I right in thinking I need a separate zip for each site - because the IIS config step pertains to only 1 site being created?
So then looping back to my first question, I’d need to edit 10 steps, each time I wanted to either upgrade a customer, or create a new one?
I have many many more questions about the rest of the process, but if the process we do at the moment doesn’t seem possible to manage with Octopus Deploy then I guess I should stop here.
Trying to create a case at work for getting some automation software.
Most steps tend to permit customization via variables. I haven’t used IIS-specific steps myself, but for any given setting you can typically click Bind to link that field to a variable that you set up in the Project Variables section of the project or to a global Variable Set that you configure in the Library tab.
How exactly you would use the variables depends on your setup, whether these sites are on ten separate physical machines or ten sites on the same IIS instance. The Octopus documentation page has more on how exactly you can use them in various contexts.
You can configure Octopus to prompt the user to enter a variable at deployment time, but in my experience this is a bit clunky and hampers the one-click automated nature that is most valuable to our use. From what little I know of your process, my guess would be you’d want a project with the same IIS step cloned 10 times (one step per site), each time referencing a different variable in the project (“CustomerAName”, “CustomerALevel”, “CustomerBName”, “CustomerBLevel”, etc). Updating any actual customer info would be done on the variables page, and then pushing changes to all ten sites at once is accomplished with just the one click.
If all ten sites are in the package, that should work fine (we do something similar at my company). When deploying, the package is unzipped in a temporary directory at C:/Octopus/Applications, and then you can make a step that copies site A’s files to C:/Web/Sites/SiteA or whatever, and then a step to copy site B’s files, etc. It’s not unusual to have dozens of steps in a single project; if it takes three steps for you to set up an IIS site normally, then your project might end up with 30 steps right there.
Steps run on roles, not specific machines. Instances can be tagged in 1 or more roles.
If you want to deploy all 12 things at once. Create a single project with multiple deployment steps. Each step in the process will deploy one of the packages (either as a service or a site). You can create variables for the project that will be applied to the .config files for each step. Each step should be self contained. Deploy the app, update the configs, start the service. (instead of deploy all the apps, update all the configs, start all the services).
If you are deploying those apps to multiple customers, look into the tenants feature of octopus.
Thanks for getting in touch! And thank you to Christian and @estubbs for your valuable input! When deploying multiple instances of a single app (one per customer), we do generally recommend taking advantage of our multi-tenancy feature (as estubbs pointed out). This allows you to deploy the same app multiple times to the same environment and define tenant-specific values for each. Multi-tenancy requires some architectural setup, and we have a ton of wonderful documentation around this feature so I’d recommend looking through if it’s the route you’d like to take.
We also have a page outlining how to work with tenant-specific variables which will probably be very helpful.
Don’t hesitate to reach out if you have any further questions going forward!
This and the other posts here have been great so far.
I’ve done a little playing around and gotten 2 Tenants setup, and I can deploy to both at once.
Couple of outstanding issues however;
If I re-deploy, it writes to a new folder for the sites, but with an underscore, and whatever iteration it is.
e.g. TestSite1\Version_1
Is there a way to simply re-write over the existing files?
At the moment, when we upgrade an environment (this means sites and services in our case) we take a backup, then essentially overwrite the folders/files with the new versions.
I suppose this is sort’ve doing that, as I have TestSite\Version, and also TestSite\Version_1, but it looks messy as it makes new names each time - Considering we might have a new version each week.
I’m open to suggestions though, maybe our standards simply need changing, we’ve made it up as we’ve gone along.
The binding seems to default to 80.
I know I can specify a port, but I need them to be a different for each site (And then increment for each Tenant)
For example, I’ve deployed to 2 tenants, and I have 2 sites sitting on port 80.
I tried setting the binding to be 600-800, in the hopes it’d auto increment as it goes through the sites (Cust1App:600, Cust2App:601), but it still defaulted to 80.
What is recommended practice around this?
Thanks for following up! That’s great to hear these posts have been helpful so far!
The new folder you’re seeing (i.e. Version_1) is created when you deploy the same package version multiple times, and will be incremented continually on subsequent deployments using the same package version. Unfortunately there’s no way to overwrite an existing deployment folder like this. You could define a custom installation directory, which will move the extracted package contents to the same specified directory each time.
You can define a unique port per tenant via tenant variables, then bind the port field to a variable for it to resolve per tenant. Could that work for you? Unfortunately I’m unaware of a way to accomplish auto incrementing the port number.
I hope this helps! Don’t hesitate to reach out if you have any further questions.
