Best Practice to Upgrade Umbraco Across Multiple Environments
I have three environments that I am working with for this current project. We have Development, Stage, and Production. Each environment has its own database so I am curious what would be the best practice to upgrade these environments from 7.4.3 to 7.5.6.
Please note: I realize Umbraco Cloud would do this for me automatically; however, at this time we are unable to use it.
Also know that we are currently using FileSystem Publish method via Visual Studio 2015 to move changes to each environment. Any "structural data" changes are being synchronized via uSync and any "content data" changes are being moved manually.
I have heard that Umbraco Courier would be a good solution to synchronize both structural and content data but we haven't had a lot of content that has needed to be synchronized yet.
So back to my original question I would like to understand the best practices more experienced umbraco developers would recommend I use to upgrade all three of my environments.
One more thing to note: Since I am using nuget to install umbraco I read it was best to use nuget to upgrade umbraco.
Now with this information here are the steps I am planning to take (at a high-level) to upgrade my environments:
Upgrade the development (local) umbraco using nuget to v7.5.6
Run the local website to verify umbraco is upgraded to v7.5.6
Deploy to the stage environment via VS FileSystem Publish
Run the stage website to verify umbraco is upgraded to v7.5.6
Deploy to the production environment via VS FileSystem Publish
Run the production website to verify umbraco is upgraded to v7.5.6
With the above steps my concern is that will the database upgrade changes be applied to each environment using these steps or do I need to use a different approach.
I would appreciate any feedback or suggestions on best practices of how to upgrade multiple environments when the development environment is using nuget to install umbraco.
Does this mean that during the upgrade in production the website will be unavailable or "kick people out"?
Is there an option or way to do the upgrade without kicking people out of the application?
Thankfully for now our app is not used 24/7 so we could do the upgrade during off hours or late in the evening but this isn't an ideal long-term solution for our product which is built on Umbraco.
There's no "kicking out", visitors will not be able to browse the site during the upgrade though.
Website visitors will see the Umbraco login screen while the upgrade is running, it's a long-standing wish of ours to have a more friendly holding screen for that but it doesn't exist.
Currently it is best practice to set up a seperate IIS site with an index.htm that says something about maintenance.
You can switch hostnames between that site and your live site while doing the upgrade on the temporary hostname. That way at least your website visitors will not be confronted with the Umbraco login screen.
I did what I described above in my Stage environment but I get this error when running umbraco from a browser on my machine (not the stage server).
Any ideas why it would be looking at my local machine and not the web server? Also any chance I can bypass this to get my stage site back up? I see the database migration record is in there for 7.5.6 but I can't seem to bypass because it continues to fail to modify the web.config because it doesn't exist on my local machine.
Could this mean the permissions on the web server aren't setup correctly for access to the web.config or is it looking on my local machine?
We are facing a similar problem, but do you know about any documentation/best practices to upgrade the Umbraco version on multiple server setups?
i.e. We have a site that uses load balanced and we have 5 servers, one of them is where the database is located, but when we implement the changes on the main server, the replicas will also have the old version in the web.config file and then authorize the upgrade on the main server, but the same version will be on the other servers since the deployment of the changes is through DevOps, so the replicas will throw an error and the site will not be accessible on those servers.
We are going to upgrade from version v8.18.8 to v8.18.10 which is about to be released
Yea, I don't know what I was thinking...I must have been tired...it's what I get for working so late last night. Of course it is on the stage server.
I'll check the logs this morning and permissions of the web.config.
I would be surprised if publishing from VS2015 could have changed permissions. I'm wondering if permissions weren't setup when the site was setup or if they were reset some out inadvertently. I want to prevent this from happening with future upgrades so any suggestions are appreciated.
Best Practice to Upgrade Umbraco Across Multiple Environments
I have three environments that I am working with for this current project. We have Development, Stage, and Production. Each environment has its own database so I am curious what would be the best practice to upgrade these environments from 7.4.3 to 7.5.6.
Please note: I realize Umbraco Cloud would do this for me automatically; however, at this time we are unable to use it.
Also know that we are currently using FileSystem Publish method via Visual Studio 2015 to move changes to each environment. Any "structural data" changes are being synchronized via uSync and any "content data" changes are being moved manually.
I have heard that Umbraco Courier would be a good solution to synchronize both structural and content data but we haven't had a lot of content that has needed to be synchronized yet.
So back to my original question I would like to understand the best practices more experienced umbraco developers would recommend I use to upgrade all three of my environments.
One more thing to note: Since I am using nuget to install umbraco I read it was best to use nuget to upgrade umbraco.
Now with this information here are the steps I am planning to take (at a high-level) to upgrade my environments:
With the above steps my concern is that will the database upgrade changes be applied to each environment using these steps or do I need to use a different approach.
I would appreciate any feedback or suggestions on best practices of how to upgrade multiple environments when the development environment is using nuget to install umbraco.
The first half of this blog post describes how we detect that your database needs an upgrade after pushing your code to a different environment: https://cultiv.nl/blog/using-umbraco-migrations-to-deploy-changes/
In short: the upgrade installer screen will run on each environment and DB changes will be applied during that required step.
Sebastiaan,
Does this mean that during the upgrade in production the website will be unavailable or "kick people out"?
Is there an option or way to do the upgrade without kicking people out of the application?
Thankfully for now our app is not used 24/7 so we could do the upgrade during off hours or late in the evening but this isn't an ideal long-term solution for our product which is built on Umbraco.
There's no "kicking out", visitors will not be able to browse the site during the upgrade though.
Website visitors will see the Umbraco login screen while the upgrade is running, it's a long-standing wish of ours to have a more friendly holding screen for that but it doesn't exist.
Currently it is best practice to set up a seperate IIS site with an
index.htmthat says something about maintenance.You can switch hostnames between that site and your live site while doing the upgrade on the temporary hostname. That way at least your website visitors will not be confronted with the Umbraco login screen.
I'm curious how Wordpress does it but this is a work around I can use for now.
Thanks for the info, Sebastiaan!
Sebastiaan,
I did what I described above in my Stage environment but I get this error when running umbraco from a browser on my machine (not the stage server).
Any ideas why it would be looking at my local machine and not the web server? Also any chance I can bypass this to get my stage site back up? I see the database migration record is in there for 7.5.6 but I can't seem to bypass because it continues to fail to modify the web.config because it doesn't exist on my local machine.
Could this mean the permissions on the web server aren't setup correctly for access to the web.config or is it looking on my local machine?
It can't look on your local machine so it seems to be permissions on your stage server. Also check the logs on your stage server.
Hello Sebastiaan,
We are facing a similar problem, but do you know about any documentation/best practices to upgrade the Umbraco version on multiple server setups? i.e. We have a site that uses load balanced and we have 5 servers, one of them is where the database is located, but when we implement the changes on the main server, the replicas will also have the old version in the web.config file and then authorize the upgrade on the main server, but the same version will be on the other servers since the deployment of the changes is through DevOps, so the replicas will throw an error and the site will not be accessible on those servers.
We are going to upgrade from version v8.18.8 to v8.18.10 which is about to be released
I hope you can help me!
Yea, I don't know what I was thinking...I must have been tired...it's what I get for working so late last night. Of course it is on the stage server.
I'll check the logs this morning and permissions of the web.config.
I would be surprised if publishing from VS2015 could have changed permissions. I'm wondering if permissions weren't setup when the site was setup or if they were reset some out inadvertently. I want to prevent this from happening with future upgrades so any suggestions are appreciated.
is working on a reply...