Hi, I’m currently working with SharePoint (poor me) but I’m interesting on migrating the site to Umbraco and so far I’m very pleased with what a learn but...
I’m wondering how to handle multiple environment. Basically, what I want is to have a development, test, acceptance and production environnement. Before doing any deployment on test, acc or prod, I’d like to be able restore the production on my dev, meaning, the current structural data, the current version of my code and the current data of production. Then I want to be able to install my new code to see if it works, this way, I’ll be sure that deploying it in production will work.
Why is want to restore prod in dev ? Say I’m doing a deployment on test but my code does not work as expected... I fix it and do another deployment and now it works... this does not ensure that deployment in production (only the final version of the code will work), it might be that it work in test BECAUSE there were a failing code version then a correct one.
Bottom line, what is the best way to manage multiple environment with umbraco ? I found some article but they were pretty outdated...
uSync is a great package to assist in deploying Umbraco based configuration changes (document types, data types, etc) - it ensures consistency when moving through environments, and I guess by default, backwards compatibility if restoring from live to dev.
One concern with your thought re backwards restores is the binary files - any compiled code is obviously not able to be copied backwards. But other than that issue, if copying down from live, you do need to replace the entire media directory so as to synchronise media objects with the dB.
Hope this helps get you moving forward with Umbraco - you won't regret it.
I had a look at uSync and it is nice indeed. For the binaries, it's not really a problem, I think, the idea is just to restore the live env to dev, and directly upgrade it afterwards with the new solution. The code will be in GIT, so I just have to make a package with the code, backup the db and the media folder, put all of this in an IIS folder and I guess I'm good to go.
However, there's still something that is not clear. Say I have a dev environement on my machine. I created a new Visual Studio web site, added the Umbraco package, installed uSync and made all my change. Say I want to host it on Azure (I know UaaS exists but it's not the topic). I read that I have to clear the connectionString settings in the web config to run the wizard on Azure, which I did and indeed, I executed the wizard, the infra responsible entered the Sql Azure information and everything worked as expected. It was the very first deployment of the site on Azure, so it's acceptable to be forced to run the wizard to setup everything.
However, few weeks after this, I need to implement a new big change on my site. Therefore, on my dev environment, I revert my web.config modification to point again on my SDF file and I implement my change. Now I'm ready, I can publish it on Azure, however, I changed so many files (the web.config included for the revert), that, to be sure not to forget anything, I want to republish all, BUT I don't want, after the publish, to be forced to go on Azure and re-run the wizard, although I'll face the issue.
Indeed, either I update all but then, my web.config will reference the SDF file and my site won't work, or I'll change my web.config but... as a developper, I'm not supposed to know the password to the Sql Azure database (an infra guy is supposed to take care of that), so what can I do with my web.config to be able to publish all my site again without having to run the wizard again?
Simplistically for deployments of site functionality changes, in principle, you should never deploy the web.config if it has environmental variables within it.
So without fully knowing your setup you could exclude the web.config from any deployment routines.
Alternatively one possible option to get around this specific issue is to move the connection string to a separate file.
We use the above for a MVC site which is not Umbraco based and it certainly works well for that site - I have no direct experience using this concept for Umbraco based sites.
Umbraco won't be able to update the user.config file - my thought/ intention was to migrate the string to the file once you have the site setup and running, as opposed to an initial deployment.
the web.config can and does occasionally get changed with upgrades, and from my experience, it is something you need to manually manage when doing upgrades - for standard updates of functionality you should need to touch the file.
At the end of the day it is about having a robust process and ensuring you follow it, and once a deployment is complete undertaking a sanity check of the site to ensure you have mucked anything up.
Multi environment best practices
Hi, I’m currently working with SharePoint (poor me) but I’m interesting on migrating the site to Umbraco and so far I’m very pleased with what a learn but...
I’m wondering how to handle multiple environment. Basically, what I want is to have a development, test, acceptance and production environnement. Before doing any deployment on test, acc or prod, I’d like to be able restore the production on my dev, meaning, the current structural data, the current version of my code and the current data of production. Then I want to be able to install my new code to see if it works, this way, I’ll be sure that deploying it in production will work.
Why is want to restore prod in dev ? Say I’m doing a deployment on test but my code does not work as expected... I fix it and do another deployment and now it works... this does not ensure that deployment in production (only the final version of the code will work), it might be that it work in test BECAUSE there were a failing code version then a correct one.
Bottom line, what is the best way to manage multiple environment with umbraco ? I found some article but they were pretty outdated...
Thanks
Hi ssougnez
uSync is a great package to assist in deploying Umbraco based configuration changes (document types, data types, etc) - it ensures consistency when moving through environments, and I guess by default, backwards compatibility if restoring from live to dev.
One concern with your thought re backwards restores is the binary files - any compiled code is obviously not able to be copied backwards. But other than that issue, if copying down from live, you do need to replace the entire media directory so as to synchronise media objects with the dB.
Hope this helps get you moving forward with Umbraco - you won't regret it.
Nigel
I had a look at uSync and it is nice indeed. For the binaries, it's not really a problem, I think, the idea is just to restore the live env to dev, and directly upgrade it afterwards with the new solution. The code will be in GIT, so I just have to make a package with the code, backup the db and the media folder, put all of this in an IIS folder and I guess I'm good to go.
However, there's still something that is not clear. Say I have a dev environement on my machine. I created a new Visual Studio web site, added the Umbraco package, installed uSync and made all my change. Say I want to host it on Azure (I know UaaS exists but it's not the topic). I read that I have to clear the connectionString settings in the web config to run the wizard on Azure, which I did and indeed, I executed the wizard, the infra responsible entered the Sql Azure information and everything worked as expected. It was the very first deployment of the site on Azure, so it's acceptable to be forced to run the wizard to setup everything.
However, few weeks after this, I need to implement a new big change on my site. Therefore, on my dev environment, I revert my web.config modification to point again on my SDF file and I implement my change. Now I'm ready, I can publish it on Azure, however, I changed so many files (the web.config included for the revert), that, to be sure not to forget anything, I want to republish all, BUT I don't want, after the publish, to be forced to go on Azure and re-run the wizard, although I'll face the issue.
Indeed, either I update all but then, my web.config will reference the SDF file and my site won't work, or I'll change my web.config but... as a developper, I'm not supposed to know the password to the Sql Azure database (an infra guy is supposed to take care of that), so what can I do with my web.config to be able to publish all my site again without having to run the wizard again?
Hi ssougnez
Simplistically for deployments of site functionality changes, in principle, you should never deploy the web.config if it has environmental variables within it.
So without fully knowing your setup you could exclude the web.config from any deployment routines.
Alternatively one possible option to get around this specific issue is to move the connection string to a separate file.
So in the web.config you have:
And then in the user.config you have:
We use the above for a MVC site which is not Umbraco based and it certainly works well for that site - I have no direct experience using this concept for Umbraco based sites.
Hope this helps.
Nigel
Il wondering if umbraco will be able to edit the user.config file in the first wizard execution or if it will edit the web.confg. I’ll try that ;-)
However, even though excluding the web.config is a good idea, i can’t ensure that I won’t modify it someday (or maybe an umbraco update will).
I really am wondering how this is usually done.
Umbraco won't be able to update the user.config file - my thought/ intention was to migrate the string to the file once you have the site setup and running, as opposed to an initial deployment.
the web.config can and does occasionally get changed with upgrades, and from my experience, it is something you need to manually manage when doing upgrades - for standard updates of functionality you should need to touch the file.
At the end of the day it is about having a robust process and ensuring you follow it, and once a deployment is complete undertaking a sanity check of the site to ensure you have mucked anything up.
is working on a reply...