This separation is actually what makes Octopus so great! You can build a release package totally independent on the environment, and then, later on, add new environments just by typing the environment specific data into Octopus as variables.
But what if the data is more complex, for example test data or complex configuration data to be placed in databases. It could also be customer specific documentation.
The best solutions I have heart of is to include these data scripts into the release packages in separate folders, but that is not very good, since you then get an environment dependent release package, and you have to create a new release in order to add a new environment.
Can Octopus handle this situation, or have any of you a good solution to this?
If not, I would suggest a change to the Octopus architecture, so the environment specific data can be more than just a set of single dimensioned variables.
Hi Troels,
Thanks for getting in touch!
That’s an interesting idea, but not one I’ve heard requested before.
Octopus makes the assumption that everything it needs for deployment will be contained in the artefacts provided to it. In the case of Octopus, that means the Nuget packages. Octopus can perform tasks to manipulate that data, but any other resources required should be in those packages.
Regardless of how you do it, the resources for each environment will have to be stored somewhere. If you don’t want to put them in the main nuget package itself, can I suggest one of the following as a solution?
- Have a separate nuget package that contains the specific resources for each environment. You could have a deployment step with a variable in the Nuget Package ID (e.g.
MyProject.#{Octopus.Environment.Name}.Documentation) so that only the appropriate resource gets deployed.
- Use variables to identify a UNC path or URL where the appropriate data can be retrieved. A PowerShell step could download these as part of your deployment.
The assumption that you’ll have everything you need for your deployment in the Nuget packages is one that we’re very unlikely to change, but I hope one of those suggestions will work for you.
Hope that helps!
Damo
Hi Damian
Thank you very much for your answer. I think this is excactly what I need. Your number 2 solution.
The first one I do not think is a good design, if I understand it correctly, because it would require a new release for every time you have environment dependent changes.
But the second is perfect, because it isolates environment dependent data outside. Thus you can add new environments without making a new release.
I do not entirely agree with the assumption you make. Because Octopus will use both the Nuget packages AND the variable set, that resides outside the package inside Octopus. The second solution you gave me would just “expand” this metadate set from only including the Octopus variable set, to include more complex data packages also.
The only discussion left is then, if Octopus should handle this data in a more organised way, like it handles the variable set.
But abstractly, I see no difference between the variable set of Octopus and the data packages, that are just more complex.
Hi Troels,
I understand. I’m glad we’ve found a solution that suits!
The difference is we consider variables simply a way of defining configuration for environments. That is, specific folders, changes to config files, or IIS bindings, etc. that can help Octopus deploy what’s in your package. Any content beyond basic configuration would belong in the package you’re deploying. In this case, we’d consider it appropriate to create a new Release. The content of your deployment is changing (even if compiled code hasn’t changed), so you’d need a new deployment.
That said, I’m aware people use variables for more than what we intended and I think the second option is a good solution in this case. It means these additional resources can be deployed separately (or as part of the same project), and the variables are once again just used for environment-sensitive configuration (e.g. where to get additional required files for each environment).
I do appreciate your feedback and I’ll bring this up with the team in case any of them have a different opinion, or can think of another way we could build something like this into the product.
Damo
Hi Damian
Thank you for bringing this up with the team, I think we are touching an important issue about what belongs in a release package and does not.
I still believe that any data only relevant for one specific environment, should be completely left out of the package. But I recognize the solution will work for many people.