We’re investigating implementing Octopus, but we would need assistance with how we would implement something we currently do in our in-house tool.
So, our build version numbers are currently in the format x.x.x.x-Cz, where x is the version number of the overall build, with z being the “config version”, e.g. 12.1.12.4-C2 would be the second version of the configs for build 12.1.12.4.
The reason this is done is because some of the applications are huge (I know…), and to have to rebuild the whole app and redeploy it for a minor config change would take an eternity. So they just re-generate new configs during the ‘build’ and then only deploy the configs overwriting those that are already there.
Is there any sensible way to emulate this in Octopus? We had thought of creating separate NuGet packages for the code and the configs, but how would this work version-number wise? And would the ‘skip packages that are already deployed’ setting work correctly to avoid re-deploying the code if we’ve only changed the configs?
My recommendation would be to leverage Octopus Deploy to manage your configuration. As you may be aware, Octopus has the concept of variables, which can be scoped per environment (as well as per project, role, etc). When deploying, Octopus can transform your configuration files. This means you can change the values of these variables in Octopus Deploy, and redeploy the same package without having to re-compile and re-package your code.
The above is certainly our recommended approach to solving your problem, and is the one the majority of our customers use. You probably could use config-only packages, and redeploy (into the same directory as your ‘application’ package) these on config-changes. However, I must stress this would not be the recommended approach.
In summary, you situation is exactly what Octopus Deploy was designed for; you just may have to change your current process a little to get the most value.
I hope this helps. Please don’t hesitate to get in touch if we can provide any more information!
We have looked at using Octopus variables, but unfortunately due to the sheer numbers of settings in some of the configs (yes, I know…) the UI as it is currently really wouldn’t work for us. We may go the ‘separate config package’ route and combine that with T4.
Quick question - if we use T4 to do the majority of our transforms, is it possible to use Octopus variable substitution together with this, so that we could store the likes of database passwords in Octopus where they can be access-controlled and encrypted?