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:

<connectionStrings configSource="user.config" />

And then in the user.config you have:

<?xml version='1.0' encoding='utf-8'?>
<connectionStrings>
<remove name="umbracoDbDSN"/>
<add name="umbracoDbDSN" connectionString="*************" providerName="System.Data.SqlClient"/>
</connectionStrings>

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...