Different roles and force redeploy

Legacy Uncategorised
#1

We are feeding our install scripts with variables from octopus based on roles (could also be environment etc)

We’ve discovered we need to force redeploy of all our packages during deploy because octopus bases the install on machine, and not on machine+roles+environment.

This is very cumbersome because what could take us 3-5min now can take 40-50min (we have alot of packages to install and they all need to be “force redeploy”).

Would it be possible to add a global setting in octopus where we can tell octopus what determines if a nupkg is installed on a machine or not? (In our case that would be nupkg-id + machine + role)

#2

Hi Ivar,

Thanks for getting in touch! Do you think you could provide a deployment log and a screenshot of your package step for this project.
I don’t know if I am fully grasping the problem here, but also would like to trace what Octopus is doing and why it isn’t finding your packages.
Sounds like it could definitely be a bug, but we will need to replicate it to understand the issue.

Thanks!
Vanessa

#3

Hi, before I do that, let me just clarify. It doesn’t have anything to do with not finding packages. It has to do with octopus deciding wether or not to install the package.
If octopus finds that it has already installed the package, it doesn’t re-install it. Which is a very good feature.

Our nupkg Deploy.ps1 is getting fed install values from octopus, based on the target machine role. This means the same nupkg can be installed in multiple ways, depending on how many roles the machine have. Our problem is that octopus decides the package is already installed based purely on nupkg ID and machine, not on the combination of machine+role+environment (the same machine can be in multiple environments)

#4

Hi Ivar,

Thanks for the explanation, I now understand. So I’ve had a talk to the devs and we can’t think of even a hacky solution for this for you. No variables to be hijacked and no way to change that path.
I have created a UserVoice suggestion to make this variable be user defined. http://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6352640-add-an-ability-to-define-your-own-package-install
Please go and vote and comment. If I can see an ability to have this added to a current feature I might try to push for it. Unfortunately right now nothing being developed is related to that area of deployment.

Vanessa

#5

Hi, a bit of clarification:

If, in Octopus Deploy, you have a server with two roles, say “external” and “internal” (different web sites on same server), and you want to publish the same web application for both external and internal users, Octopus Deploy will only deploy it once.

I have bent my mind around this, but haven’t found any single scenario where you want the “scope” of “have I installed this package before?” to be “server”, and not “role”. Can you think of one?

Example:

Server1 (only role “internal”):

Server2 (only role “external”):

Server3 (both roles “internal” and “external”):

With today’s implementation in Octopus Deploy, Server3 will only get one of the instances of MyApp installed (depending on whichever is installed first). I really can’t find any real-world scenario for this behaviour.

We would like to have Octopus consider roles as well when deciding whether an app has been installed or not.

“Have I installed MyApp for role ‘internal’ on this server?”
“Have I installed MyApp for role ‘external’ on this server?”

Positive side effect

In the folder structure, it’s much easer to find one’s way in the packages. Instead of this folder structure, which, when it grows, is rather unmanageable (how do I know which role(s) the “Employee-web” belongs to?):

E:\Octopus-apps\DEV5\Authentication-Web\2014.11.01.10_1
E:\Octopus-apps\DEV5\authentication-service\2014.11.01.10_1
E:\Octopus-apps\DEV5\Customer-Web\2014.11.01.10_1
E:\Octopus-apps\DEV5\Customer-service\2014.11.01.10_1
E:\Octopus-apps\DEV5\Employee-Web\2014.11.01.10_1
E:\Octopus-apps\DEV5\Employee-service\2014.11.01.10_1
E:\Octopus-apps\DEV5\Authentication-Web\2014.11.01.10_2
E:\Octopus-apps\DEV5\authentication-service\2014.11.01.10_2
E:\Octopus-apps\DEV5\Customer-Web\2014.11.01.10_2
E:\Octopus-apps\DEV5\Customer-service\2014.11.01.10_2

you would get the following:

E:\Octopus-apps\DEV5\external\Authentication-Web
E:\Octopus-apps\DEV5\external\authentication-service
E:\Octopus-apps\DEV5\external\Customer-Web
E:\Octopus-apps\DEV5\external\Customer-service

E:\Octopus-apps\DEV5\internal\Authentication-Web
E:\Octopus-apps\DEV5\internal\authentication-service
E:\Octopus-apps\DEV5\internal\Customer-Web
E:\Octopus-apps\DEV5\internal\Customer-service
E:\Octopus-apps\DEV5\internal\Employee-Web
E:\Octopus-apps\DEV5\internal\Employee-service

or, if you split web and service into different roles (i.e. external-web, external-service, internal-web, internal-service), even more structured and organized:

E:\Octopus-apps\DEV5\external-web\Authentication-Web
E:\Octopus-apps\DEV5\external-web\Customer-Web
E:\Octopus-apps\DEV5\external-service\authentication-service
E:\Octopus-apps\DEV5\external-service\Customer-service

E:\Octopus-apps\DEV5\internal-web\Authentication-Web
E:\Octopus-apps\DEV5\internal-web\Customer-Web
E:\Octopus-apps\DEV5\internal-web\Employee-Web

E:\Octopus-apps\DEV5\internal-service\authentication-service
E:\Octopus-apps\DEV5\internal-service\Customer-service
E:\Octopus-apps\DEV5\internal-service\Employee-service

I really can’t see any good argument for Octopus’ current behaviour, but I might of course be wrong. Could you think of a sensible use case for the current behaviour?

Thanks :slight_smile:

#6

Hi Erik,

I take your point that roles could/should probably be factored in to the ‘have I installed this before’ reasoning. At this stage, I think it’s too late of a change to make - there would be too many people relying on the current behavior.

That said, assuming you have two deployment steps:

Step A: Install package MyApp to role: external
Step B: Install package MyApp to role: internal

Out of the box, Octopus will allow both to execute on the same machine, since we no longer check whether the package is already installed (we always install). This behavior can be controlled from the project settings page - perhaps you have it turned off? (We turn it off when a project is imported from Octopus 1.6).

Another workaround would be to define a special project-level variable called:

Octopus.Tentacle.CurrentDeployment.RetentionPolicySubset

And bind it to:

 #{Octopus.Tentacle.CurrentDeployment.TargetedRoles}

When we work out whether the package is already installed, or for calculating retention policies, this field is used to differentiate different steps that might use the same package.

Thanks again for the feedback, and for what it’s worth I agree, but I just don’t think it’s something we can change now. Hopefully the above suggestions help!

Paul

#7