Upgrading from 7.5.13 (7.5) to 7.6 (and upgrading umbraco, generally)
Hi :)
I am trying to map out the best way to upgrade Umbraco nuget 7.5.13 to 7.6.
I have read the upgrade information link that tells you generally how to upgrade:
-upgrade from nuget;
-say no to overwriting .config files;
-download the .zip of the version you're upgrading to
-then use winmerge to see what has changed in the .config files.
Although this is explanatory, I find it a bit vague. A few questions come to mind:
Do I make all changes when it comes to the differences between .config files?
Surely I do not make all changes with web.config, since it will break the website...I've tried going through the file in detail using winmerge and even when meticulously trying to keep the customize xml that I added to the web.config, the website would still break (from past upgrading experiences).
Which .config files do I change, and which ones do I leave alone?
Also, if I have a live version of the website on the server (that obviously would have different additions to the database, due to user input, compared to my local version), do I sync databases first in visual studio and sql db manager (in an attempt to mimic the live website database on the local machine) before upgrading the local version, and then upgrade the local version?
Perhaps I am missing some questions here. Feel free to add some missing questions / mappings.
This is my approach and depending on your own governance around releasing to a live environment things will change drastically.
Pre-upgrade
The site should be under some type of source control. I also add Umbraco into SC, not just my changes. I know technically Umbraco is already sourced controlled so why do it again but I like to see the diff between files before and after the upgrade. Git is my weapon of choice here.
Copy live DB and restore into your dev environment *
For me in order to preserve any changes I have been working on that affects the database I use uSync to manage changes. Therefore I before a restore I will do a uSync export and source control it. I have a strict release pattern so changes only flow one way. I never change the underlying types in live they are only pushed via uSync import into live via a build server.
Also for an upgrade I create a diff script of the database changes. Again this is unique to me as the DB account running Umbraco is generally not allowed to make schema changes to the live DB. It's very locked down. I use Ready Roll project in VS to do this is compares before and after the upgrade and it gives you a nice sql migration script. I prefer this approach as it's repeatable and you can add it into any build server.
Upgrade time
Run ready roll (current schema)
Upgrade Umbraco using the Package Manager Console in Visual Studio e.g Update-Package UmbracoCms -version 7.6.0 I always set the version number against my packages.
As I have everything under SC I am fine with letting it overwrite all my configs. I know it's going to break, that's fine as we are in dev. Some people prefer to keep changes and try and patch the files after if it doesn't work when they spin up the site but I prefer to take the vanilla configs and then layer my changes on top.
Run ready roll (capture changes to schema)
Next I will use SC to do a diff on what has changed. VS is great and showing you all the changes. You now need to get the before and after up on the screen and merge left to right taking your custom changes across.
It's probably a little slower doing it this way but at least this way I know exactly want is needed and how the configs have changed.
It's important also to read about breaking changes and where for example a package has been adopted into the core. Property Converters is a great example in 7.6.0 where I can now remove an external package and may need to make minor adjustments.
Once I have it working on dev I commit the changes and create a pull request on the deployment branch and run the build server. I will also add the DB migration scripts in.
Part of a release is that it also does a backup of site and DB again and turns off editing on the site so we have a way back if the upgrade fails but at this point we have done a few dry runs on other dev build servers.
Just make sure you backup, source control and read the breaking changes and it is normally a very smooth process.
I should probably start using Git. I just have to find an easy way to get git on my host server as well...any ideas?
Also, I'm not seeing how you can easily make the changes to the .config files after allowing the overwrite. How will you know what is essential and what is not?
On thing I'd add is that I actually compare the .config files with the previous version from umbraco's download site matching what I have installed. Meaning if I upgrade from 7.5.10 to 7.6, I go download 7.5.10 and 7.6 and use a diff tool like beyond compare to compare the files (or directories) to determine what really changed.
I find this much easier particularly when you have several other packages installed, sometimes it is difficult to see exactly what has changed because of the upgrade vs. what is different because of other packages.
John makes an excellent suggestion. One way or another you need to do a compare of the config files. If you want to use git then using tools like tower or source tree are best as they supports partial staging of files e.g. just a few lines. In VS i don't think you can do partial stages of files, well not easily.
With regards to getting git on your server it will depend on your host. But you don't need it. I use git ftp with shared hosting to manage small sites if you can't afford a vps with Git.
Upgrading from 7.5.13 (7.5) to 7.6 (and upgrading umbraco, generally)
Hi :)
I am trying to map out the best way to upgrade Umbraco nuget 7.5.13 to 7.6.
I have read the upgrade information link that tells you generally how to upgrade:
-upgrade from nuget; -say no to overwriting .config files; -download the .zip of the version you're upgrading to -then use winmerge to see what has changed in the .config files.
Although this is explanatory, I find it a bit vague. A few questions come to mind:
Which .config files do I change, and which ones do I leave alone?
Also, if I have a live version of the website on the server (that obviously would have different additions to the database, due to user input, compared to my local version), do I sync databases first in visual studio and sql db manager (in an attempt to mimic the live website database on the local machine) before upgrading the local version, and then upgrade the local version?
Perhaps I am missing some questions here. Feel free to add some missing questions / mappings.
Hi,
This is my approach and depending on your own governance around releasing to a live environment things will change drastically.
Pre-upgrade
The site should be under some type of source control. I also add Umbraco into SC, not just my changes. I know technically Umbraco is already sourced controlled so why do it again but I like to see the diff between files before and after the upgrade. Git is my weapon of choice here.
Copy live DB and restore into your dev environment *
Also for an upgrade I create a diff script of the database changes. Again this is unique to me as the DB account running Umbraco is generally not allowed to make schema changes to the live DB. It's very locked down. I use Ready Roll project in VS to do this is compares before and after the upgrade and it gives you a nice sql migration script. I prefer this approach as it's repeatable and you can add it into any build server.
Upgrade time
Run ready roll (current schema)
Upgrade Umbraco using the Package Manager Console in Visual Studio e.g Update-Package UmbracoCms -version 7.6.0 I always set the version number against my packages.
As I have everything under SC I am fine with letting it overwrite all my configs. I know it's going to break, that's fine as we are in dev. Some people prefer to keep changes and try and patch the files after if it doesn't work when they spin up the site but I prefer to take the vanilla configs and then layer my changes on top.
Run ready roll (capture changes to schema)
Next I will use SC to do a diff on what has changed. VS is great and showing you all the changes. You now need to get the before and after up on the screen and merge left to right taking your custom changes across.
It's probably a little slower doing it this way but at least this way I know exactly want is needed and how the configs have changed.
Once I have it working on dev I commit the changes and create a pull request on the deployment branch and run the build server. I will also add the DB migration scripts in.
Just make sure you backup, source control and read the breaking changes and it is normally a very smooth process.
Hi David,
Thanks so much! This is very helpful.
I should probably start using Git. I just have to find an easy way to get git on my host server as well...any ideas?
Also, I'm not seeing how you can easily make the changes to the .config files after allowing the overwrite. How will you know what is essential and what is not?
Thanks.
On thing I'd add is that I actually compare the .config files with the previous version from umbraco's download site matching what I have installed. Meaning if I upgrade from 7.5.10 to 7.6, I go download 7.5.10 and 7.6 and use a diff tool like beyond compare to compare the files (or directories) to determine what really changed.
I find this much easier particularly when you have several other packages installed, sometimes it is difficult to see exactly what has changed because of the upgrade vs. what is different because of other packages.
Hi
John makes an excellent suggestion. One way or another you need to do a compare of the config files. If you want to use git then using tools like tower or source tree are best as they supports partial staging of files e.g. just a few lines. In VS i don't think you can do partial stages of files, well not easily.
With regards to getting git on your server it will depend on your host. But you don't need it. I use git ftp with shared hosting to manage small sites if you can't afford a vps with Git.
Thanks for the advice guys. Your suggestions make sense, especially since there isn't really any detailed changelog.
David, I actually do have a vps, so that's why I have to look into getting git on the server.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.
Continue discussion