Relationship between environments / machines

This post might be borne out of a fundamental misunderstanding of how Octopus is designed - hopefully someone can put me straight!

I have a requirement to have multiple environments on the same machine. So we would install different versions of the same software side-by-side (in different folders with different config). Often the same version of software might be installed in the two different environments on a particular machine. How does Octopus currently handle having the same machine in different environments?

I just tried this out, setting up two environments (Development and Testing) on the same machine. Naively I expected to see the package copied to C:\Octopus\Applications{Environment},but it seems it just places everything in the Applications folder regardless of which environment I was deploying to.

A second, related, problem is controlling releases by both environment and machine. My test project would have multiple machines in its development environment, and I’d like to be able to push version XYZ to Development for Machine 1, and version ABC to Development for Machine 2, etc. Is that possible? It seems from my testing that I can push to Development, in which case ALL machines in development get the install, etc.

Like I said, I may be fundamentally misunderstanding things, so please do put me right if I am!

Lastly, a partly related question: my original push to Development failed (as I haven’t yet sorted out my installutil issues as mentioned in another question!). I was expecting that when I tried a push to the Testing environment on the same machine that it would also fail for the same reason, but it reported as a success. It appears that Octopus found the files from my push to Development on that machine, and decided it was all done and it could report a success immediately. Is it right that it didn’t try to run installutil in this case? As I was deploying to a new environment I would have thought it would have tried to install the service again.

Hi Neil,

Having a sub folder per environment is a good idea. Unfortunately, it would break one feature: when a Web project is deployed, the IIS site automatically gets updated (e.g., Acme.Web IIS website will point to the last Acme.Web package). Since two IIS sites can’t exist with the same name, this would cause a problem.

That said, I could start to prefix/suffix the IIS websites - e.g., Acme.Web.Production. I might be able to make this a project option, and then do per-environment folders as per your suggestion. I like it.

For your second issue, there are two ways to handle this:

  1. Set up a second environment, one containing machine 1, and another containing machine 2; or
  2. Set up two projects - one maps version XYZ to machine 1, the second project maps version ABC to machine 2.

Approach #2 is the way branching would normally be done, which sounds like it might be what you are doing in this case. Note that a package can be mapped to individual machines, not just all machines in an environment.

Re: your last issue, could you paste the deployment log? I suspect that a mapping may be missing - Octopus will decide that a package has been uploaded, but it will always re-extract it and re-configure it.

I hope that helps,

Paul

I like the idea of prefixing/suffixing the IIS entry - that’s currently how we do handle multiple web instances on the same machine so it would fit in naturally with our current systems.

And yes, the subfolder for environment would be very useful. Coupled with the ability to specify a different root folder for application deployment (as per http://help.octopusdeploy.com/discussions/questions/19-a-few-questions-on-package-deployment) that would easily give all the flexibility I need.

Is there a limit on how many environments I can set up per project? The method it looks like I’m going to go with is to set up a separate environment for each customer-environment combination, which will eventually be quite a lot (tens, not hundreds!). Will this screw up the site display?

Here’s the deployment log for that time it failed to run InstallUtil. Out of interest, is there a way of stopping Octopus from running InstallUtil? So if I decided I’d rather run it myself manually through the Powershell script I could do so without Octopus interfering? I realise this complicates the conventions, but I may end up going down that route.

2011-09-28 10:07:54 INFO Deploying release ‘2011.9.27.7’ of project ‘Test Service’ into environment 'UAT’
2011-09-28 10:07:54 INFO Downloading NuGet package Mnetics.TestService 2011.9.27.7 from feed: 'http://nugetserver:10418/nuget
2011-09-28 10:07:54 DEBUG Found package Mnetics.TestService 2011.9.27.7
2011-09-28 10:07:54 DEBUG Completed download of NuGet package Mnetics.TestService 2011.9.27.7
2011-09-28 10:07:56 INFO ##################################################
2011-09-28 10:07:56 INFO # STEP: 1. Mnetics.TestService
2011-09-28 10:07:56 INFO ##################################################

As you can see it stops immediately at the beginning of Step 1 and reported success. The same release being put into a different environment on the same machine ran the extraction, installutil, etc.

Hi Neil,

The reason for the empty log is because no mappings exist between the package (Mnetics.TestService) and any machines in the UAT environment. You’ll need to edit the ‘deployment steps’ for your project to specify the machine in your UAT environment.

I’ll put out a new build this weekend that will log this and make it clearer what is going on.

Paul

Hi Neil,

There are no limits, but as you say, it will probably mess with the display. I have plans to change how the Environments page looks so that it can easily handle lots of environments/machines, and similar for projects (a scrollbar may appear). I’m going to try and get around to that this weekend.

Paul

Ok, I think I understand. What I found confusing is that the deployment steps are specified at the project level, not at the environment level.

So, if I have a project that I’m deploying to twenty different machines/environments, and the deployment step is just ‘install one package’, then that step has to have all twenty machines ticked? And then when I deploy it to an environment it will install to just that one environment on just that one machine?

I think intuitively I expected deployment steps to exist per-environment, but I can see the logic of it being per project. Thanks for the explanation!

Hi Neil,

You got it, that is correct - one step with many machines ticked. The model of steps/environments/projects took a few weeks of thinking about but I hope it makes sense. Let me know if there’s anything you think I could do to make it clearer or better.

Paul