Before unattended upgrades, the advice would be to deploy the upgraded solution to the live environment with the configuration status set to be the existing version.
The upgrade uses this to run any database migrations between the existing and upgraded version, and then when finished, updates the configuration status to match the upgraded version.
This is a pain for continuous integration deployment pipelines + source control, as you have to deploy with the old version in config, then update source control afterwards with the new upgraded version number, or manually switch it after deploy and before triggering the upgrade... either way, along with having to login and authorize, it's a manual step.
In your current scenario, if your dev/upgrade environment is using the same database as live, then it will probably be ok... but if it's not, then there is a chance your current process 'could' miss a migration between versions on the production database...
What unattended upgrades brings is that subtle change to configuration approach, when deploying the upgraded version of Umbraco, eg the configuration setting now matches the version you are upgrading to, rather than the one you are upgrading from (which is what you currently do anyway!) - and it removes the requirement to 'login' to trigger the upgrade, the first request to that site after the deployment will trigger the upgrade, and the site will be slow for a bit, until the upgrade is complete.
The idea I think, is to make it easier when you have multiple servers to upgrade, perhaps with a continous integration pipeline in play, and avoiding any manual steps!
Well, there's official documentation now for 8.12+ unattended upgrades. The process seems identical to the one we are using already (which may cause problems, as you've mentioned) but it doesn't mention the deployment-across-environments-scenario.
So we're going to use this process:
Ensure unattended upgrades are enabled in configuration Upgrade the
development environment using NuGets. This bumps the
ConfigurationStatus app setting of course.
Deploy to the target
environment, including the app setting with the bumped
ConfigurationStatus.
Enjoy automatic upgrades on all servers in the target environment, hopefully, and keep hoping for official documentation on upgrades-across-environments-including-multiple-servers.
The key difference appears to be in the past the ConfigurationStatus used to be the version you were upgrading from, but now with unattended, it needs to be the version to.
With multiple environments all sharing the same database, you only want one environment to actually do the database upgrade part!
The question is in a flexible load balancing setup, is there a check to see if the server is the 'Primary/master' server or a 'Replica' - eg it might handle this automatically where only requests to the 'Primary/Master' machine will trigger the unattendedupgrade.
In which case it would be fine to deploy out to all 'at the same time', with the configuration status set to be the new version, then the first request to the Primary/master server (this might be the backoffice, so might not immediately get hit) would trigger the upgrade... hmm...
Interestingly, when upgrading to 8.12 now (from 8.11.1) the upgrader did not change the Umbraco.Core.ConfigurationStatus in Web.config. I've never had to change that manually. Is that related to unattended upgrades somehow?
8.12 Unattended Upgrades process specifics
The 8.12 release candidate documentation for Unattended Upgrades say
This is a bit unclear. Especially the "matches the assembly version" part.
However.
Our current process is
This works fine. It's a bit cumbersome for multiple-server deployments, but that's a different story.
Is the Unattended Upgrade process the same, except for step 3 being done automatically in the background?
Hi Per
Before unattended upgrades, the advice would be to deploy the upgraded solution to the live environment with the configuration status set to be the existing version.
The upgrade uses this to run any database migrations between the existing and upgraded version, and then when finished, updates the configuration status to match the upgraded version.
This is a pain for continuous integration deployment pipelines + source control, as you have to deploy with the old version in config, then update source control afterwards with the new upgraded version number, or manually switch it after deploy and before triggering the upgrade... either way, along with having to login and authorize, it's a manual step.
In your current scenario, if your dev/upgrade environment is using the same database as live, then it will probably be ok... but if it's not, then there is a chance your current process 'could' miss a migration between versions on the production database...
What unattended upgrades brings is that subtle change to configuration approach, when deploying the upgraded version of Umbraco, eg the configuration setting now matches the version you are upgrading to, rather than the one you are upgrading from (which is what you currently do anyway!) - and it removes the requirement to 'login' to trigger the upgrade, the first request to that site after the deployment will trigger the upgrade, and the site will be slow for a bit, until the upgrade is complete.
The idea I think, is to make it easier when you have multiple servers to upgrade, perhaps with a continous integration pipeline in play, and avoiding any manual steps!
regards
Marc
Well, there's official documentation now for 8.12+ unattended upgrades. The process seems identical to the one we are using already (which may cause problems, as you've mentioned) but it doesn't mention the deployment-across-environments-scenario.
So we're going to use this process:
Hi Per
The key difference appears to be in the past the ConfigurationStatus used to be the version you were upgrading from, but now with unattended, it needs to be the version to.
With multiple environments all sharing the same database, you only want one environment to actually do the database upgrade part!
The question is in a flexible load balancing setup, is there a check to see if the server is the 'Primary/master' server or a 'Replica' - eg it might handle this automatically where only requests to the 'Primary/Master' machine will trigger the unattendedupgrade.
In which case it would be fine to deploy out to all 'at the same time', with the configuration status set to be the new version, then the first request to the Primary/master server (this might be the backoffice, so might not immediately get hit) would trigger the upgrade... hmm...
But looking here:
https://github.com/umbraco/Umbraco-CMS/commit/5efc1817d66ffd59946d89c635e89d55b9769dfa
that doesn't appear to be the case...
We can raise an issue on the Documentation Tracker, to ask for clarification about unattended upgrades across multiple environments?
https://github.com/umbraco/UmbracoDocs/issues
regards
Marc
Thanks. I can raise an issue for that.
Interestingly, when upgrading to 8.12 now (from 8.11.1) the upgrader did not change the
Umbraco.Core.ConfigurationStatusinWeb.config. I've never had to change that manually. Is that related to unattended upgrades somehow?This is now covered in the official documentation.
is working on a reply...