Hi.
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,
Niklas
