Are separate configuration-deployments possible?


In our company we deploy our .NET-Projects via OctopusDeploy. Apart from that, our Server-Software, which runs under Sun Solaris, is deployed in a manual process. I’ve been working on a way to deploy those also via OctopusDeploy for about eight months now and I already thought we had it until today.
The problem is, that the server is to be installed AND configured and that configuration is also to be managed via OD.
The server is an old long term project and makes use of many different configuration files. Those are created during deployment by Octopus using values from multiple Variable-Sets.
Steps for Deployment are among others: installation, configuration (writing those files) and starting the server.

Here comes my problem/question (already simplified in many ways):
Let our server to be deployed be S.
We have a project for S in OD with one channel, the latter referring to one lifecycle. The lifecycle has three stages: DEV, TEST and PROD.
DEV is optional but TEST is mandatory for deployments into PROD.

Now assume the follwing situation:
Version 1 of S has successfully been deployed into PROD. A new Version of S, version 2, has been developed and deployed into TEST. Now someone wishes to reconfigure the Server (version 1) in PROD (let’s say changing the loglevel) by modifying the relevant OD-variables and deploying the release while skipping the installation-step. How can we do this?
(i) Imagine I would repeat the original deployment of version 1. Then I’d have to stick to the old values or manipulate them. In the latter case I would loose the former values, wouldn’t I? This would mean a no-go to us.
(ii) I could create a new release of S and deploy it skipping the installation-step…but I wouldn’t be able to deploy it into PROD without deploying it into TEST first which would be wrong.
(iii) In order to circumvent this I could create a new channel for configuration releases referring to a different LifeCycle with the same stages where no stage is mandatory for any other. Here I could create a new release like in (ii) and deploy it directly into PROD. But: How can I make sure I can only deploy a configuration-release when the Server is already installed? How I can I make sure I cannot mix a Server 1 installation with a Server 2 configuration by accident?

To me the last option (if any) looks the most promising. What are my options in order to constrain the configuration releases to some degree? What can I do to protect the admins as much as possible from messing up the deployment completely?
I hope you can understand my situation. I’m afraid it was a conceptional mistake to mix deployment with configuration-management. I’ve been into this for such a long time now that it would almost be a catastrophe if this was a dead end. I’d very much appreciate any help with this.

Thank you very much in advance,

Hi Niklas,

Thanks for getting in touch,

I greatly appreciate the level of detail provided here, this really helps out!

One solution I can think of (though it’s more of a workaround) would be to include a manual intervention step at the beginning of the Project and scope this step to only execute when using a particular channel using the step conditions (i.e. the channel that uses an alternate lifecycle to deploy releases straight to Prod when only needing to update Octopus variables, when creating a new release)

The benefit of using the manual intervention step is that it will become apparent to Users that the manual approval step is intended to make it obvious to the team that skipping TEST is not something that should be done rashly. You could even specify a team that the average user does not belong to, to create a two-factor approval step.

Having a branching strategy that supports hotfixes well (e.g. gitflow) can be advantageous too.

For your convenience, I’ve included a link to our documentation regarding using manual intervention steps below;

I hope this helps!

If I’ve misunderstood your query in any way or if you require further assistance, please let me know :slight_smile:

Kind Regards,


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