Is seems like Variable sets are captured when a deployment is created

We are using Octopus for deploying a number of applications that share variables, and so we are using Variable Sets for this purpose (server names, etc.). The problem that I am seeing is that it seems like if I create a deployment in development, then update a Variable Set variable value, then promote the deployment, it will use the old value for the variable. It seems like the Variable Set values are captured at deployment creation time.

Is this correct, or am I missing something? And if so, can it be changed? It seems bad to have to create a brand new deployment to simply change a configuration value.

Thanks,
Erick

Hi Erick,

You are correct. Variable values are captured when a release is created.

You can update a release’s variables. On the release page there is a variables section containing an ‘Update variables’ button. See the attached image.

Capturing variables with the release was a very deliberate decision. This configuration is part of a release, and in most cases should remain consistent as a release is promoted through your environments. For this reason, we generally recommend creating a new release after changing variables. But the button is always there for convenience.

I hope that helps.

Regards,
Michael

Michael,

Thanks for the quick response.

I don’t see an option to update a release’s version of a shared variable set (i.e., those variables from Library->Variable Sets). I might be missing something, so I will continue to look.

In general, what is the preferred workflow for something like updating a server name? For example, if one of the variables is server A, and that server crashes, and we bring up server B (disaster recovery server), is the recommended way to create a new release? Or should the fallback servers be something outside the scope of Octopus Deploy?

Thanks,
Erick

Erick,

From what you have described, I would manage this using environments.

You could have a ‘Production’ environment containing your production server, and a ‘DR’ environment containing your backup server.
If your prod server has issues, you deploy the current release to the DR environment. This takes care of machine names out of the box. And any other variables can be scoped to an environment (i.e. have different values for different environments).

So you don’t have to create a new release, nor update the existing one. You simply deploy it to the desired environment.

Could this work for you?

Hey Michael,

I am thinking about a slightly different tack now. What I am thinking is that the configuration files would be stored and deployed via nuget/octopus in a separate project. There would be a package for each environment, and updates to the config file would result in a new package.

The only tricky part is doing an IIS reset after a configuration update/deploy, but if I name the websites correctly in IIS (using octopus), it should work.

Let me know if you’ve seen this attempted before, or if it’s a known anti-pattern.

Thanks,
Erick

Erick,

Nothing you’ve suggested wouldn’t work, and ultimately the best approach is the one the provides you with the least friction.

The configuration package can be a solution to having shared configuration (i.e. shared between projects) that you want to manage outside of Octopus.

However, without knowing the specifics of your scenario, I’m skeptical about the package-per-environment. Personally, I find it nicer to have Octopus understand your deployment environments (and associated config), leaving everything prior in the workflow (CI server, source-code) free to be unaware. This is certainly our generally recommended approach: have your CI-server build packages that are unaware of where they will be deployed, leaving the deployments to Octopus.

Regarding the IIS reset, this (or an app pool recycle) should be easily achieved with a PowerShell step. And if you modify web.config you get an app pool recycle automatically.

If we can be of any assistance, you know where to find us.

Regards,
Michael

Thanks Michael,

We went with a slightly different approach. There is a package that contains the configuration for all environments, which is then deployed to severs. The actual setting of the values is done in an Octopus Step.

The problem that we have of using Octopus for all configuration values is one of control and security. With the configuration in source control, we have a full audit of all changes. In Octopus, we don’t have this. What I would love a way to bridge the gap - have a way for Octopus to read variable values from a file provided by a package.

Thanks,
Erick

Erick,

I don’t see why this wouldn’t be possible. Though we don’t provide out-of-the-box support for it, so it would have to be a custom solution.

If you have a package which contains your variables (in whatever format they may be), you could add a Deploy Package step, select your configuration package, and enable the Custom Deployment Scripts feature in which you write PowerShell that reads your variables and sets Octopus Output Variables. These are then available to be used by subsequent steps (i.e. the steps that deploy your application). You can utilize the Octopus.Environment.Name, to determine which variable file to read, or however you partition your environments’ configuration.

In the next minor release of Octopus Deploy (3.3), we are adding the concept of steps which execute on the server, rather than on a target (e.g. Tentacle). This would also be handy if you were implementing the solution above, as it would mean your configuration step would only need to execute once on the server, rather than on each target machine.

I hope this helps,
Michael

Hey Michael,

This makes sense. It’s not as explicit as having variable sets from a file, but it would work. I already registered the Octopus Deploy machine as a target for doing one-time tasks (as opposed to per server tasks), but it will be nice to have explicit support.

What would be really nice is the ability to store a variable set in source control, or barring that, in a file on the Octopus Server (which could be then stored in source control).

The same suggestion for Step Templates, as they actual code, and not having them under source control is concerning.

Thanks,
Erick