Just checking whether this already exists. If not I’ll have to look to write something.
We do not use transforms (at least not currently) and use configuration variables heavily. There are the occasional configuration items people would like to update and repush to the server. Currently that means updating the release and repushing the WHOLE release. Is there an existing mechanism in one of the steps where it would say, you don’t need to repush the package, but I would like you to reparse the web.config and apply these configuration updates I have just “committed”?
I realize this could be an issue with the transforms and substitution variables, but if I didn’t have to rewrite the app settings key value logic I’d be OK with that.
I don’t know if I am interpreting this correctly, but I think I mostly understand. The main issue is not so much reapplying the variable substitution, but the concern when you create a new release it will push the package again to the Tentacle?
If that is correct, then if the package is exactly the same as any previous package and within retention policy windows, Octopus will not push a package twice. It will check for the package already there, and while it will extract it again so it can reapply the variables, it won’t waste bandwidth with package push.
If it is more along the lines of ‘I do not want the package pushed, nor any other package step run only the variable replacement’ then no Octopus does not really work like that. The package is extracted to a new directory again and all of the conventions are re-run (this allows each subsequent deployment to be the same, if the order is exact and always run on a freshly extracted package you can assume that it will always have the same results, whereas reapplying conventions to an already completed deployment would give unexpected results).
You can skip conventions that run after an event with a scripted variable, but majority of the time this is not recommended as files are not moved or old files are not used. Below is some documentation on the order that we use and the variable I mentioned:
Let me know what you think or if you have any follow up questions because I have interpreted your issue terribly
Vanessa
So we have a support package and a release that has happened at a different and often faster pace (think docs like help or report definitions or images for that matter (we’ve actually at various stages had all of these)) than our main software, and yet it resides inside the directory for our main software. That means that if the main package gets updated with new configuration and we give it a new installation directory (the default behavior) we need to remember to repush the secondary package too. During a release of the software that is easy enough to remember and plan for. However there are times where if you are firefighting or someone else answers a ticket to update a configuration item (and in doing so repush the main package) that it is a case where they or I will miss that they have to push the secondary package and thus things are broken. Because of paperwork creating a new release for the main package isn’t always easier or feasible for things that ultimately are viewed as configuration.
Yes there are definitely alternatives. Yes I know it would miss somethings, but just trying to go through and order and eliminate options.
Is the secondary package in the same project or are they different projects? It feels like Octopus could handle this for you if they were in the same project, and both steps were pushed. If one hasn’t changed version number it would never be repushed nor deleted in any retention policy and would in situations where you do need to firefight just be available without the need for potential human error. I might run this past a few more team members and see if they can see other alternatives or figure out what I am missing.
Sorry this got lost in the inbox. Unless I’m missing something obvious, this suggestion would force an update to the release number, which would cause changes to the paperwork.
Right?
Anyways, I think I have my main answer (no there really isn’t a way built in)
I still think neither of us are on the same page with this.
If you had release 1.2.1 with package 1.2.1 for your main package and package 1.0.2 for the support package
When you create a new release for a new package for your main package that is 1.2.2 the support package would still be 1.0.2 and wouldn’t require to be uploaded again with the new main package.
If you had to quickly get a hotfix out a new release again would just use the latest support package that is already on that server and again doesn’t need to be repushed, it would just deploy.
I can again try to use better words or an example if this isnt any clearer.
Vanessa
You’ve got half of the situation described perfectly. The thing is, it is the support package that is more likely to be updated with new stuff (or at least that’s what I was told when I built it), and they don’t want a new main release every time they update the support release. So, if we have done a release to production with 1.0.0, and now we have a 1.0.3 (and then 1.0.4-1.0.10) support package, they aren’t wanting to update the overall release to be 1.0.1-1.0.10, especially since what they are asking to promote they view as configuration anyways (no DLLs or code involved in this case). Configuration doesn’t take (boatloads of) additional paperwork, releases do.
I think I am totally on the same page as you are now. So I have good (and bad news). Bad news first, you are correct this cannot be done with Octopus currently.
Good news is that it is planned: https://github.com/OctopusDeploy/Issues/issues/2755
While it does specifically mention Tenants I had a chat to the dev who wants this feature championed and it will be available outside of tenanted deployments.
Currently while it is still a little up for debate the direction will be something along the lines of ‘At deployment time, one of my packages will check for the ‘latest’ version while the main package stays as it was defined’.
Please have a read through the thread and add your own comments or use case as it will help with the features design.
It won’t be right in the new year, but it is a feature we would like to see picked up in 2017.
