Hi Simon,

The main thing to note is that you don't / shouldn't publish the actual database when deploying Umbraco - mainly because it has all sorts of internal IDs and the like in it that unless you are keeping the sites in perfect symmetry (so never creating anything not even a new page on the deployed site) things will get messy quickly.

uSync takes the bits of umbraco that are stored in the DB and copies them to disk and then puts them back into your other DB at the other end - handling any changes in internal IDs and the links between them - so i would say (because i wrote it) that uSync be the answer you are looking for here.

Typically I would start with a local DB (CE or not) and have uSync keeping everything in sync on the disk. This is then your source controlled version of the site. The advantage with this is that other developers can pick up the site and work locally without having to worry about database access, and you can deploy to azure or IIS or what ever without worrying to much about changing the developer setup.

Deployment wise: It depends on how you are generating your deployment - if you are using WebDeploy from within visual studio (or from a build server like Visual Studio Online) then the uSync folder will be included in the subsequent deployment, and when you copy everything up to azure (or when visual studio does it for you) the changes will also be copied over, and applied on the target site when it starts up.

There is a little bit of a thing you have to do to see the DB for the first start, but once that is done it's all automagic.

I have a couple of posts that go through some of the setup options for uSync and might help: http://blog.jumoo.co.uk/c/usync/

Hi Simon

In follow up to Kevin's response, and as a non biased user of uSync (sorry, Kevin it had to be said - hehe), I totally concur with Kevin's comments.

uSync is perfect for replicating changes through test / lives sites and provides a quick and simple interface for implementation thereof. It is my "goto" for all sites when considering your issue.

Cheers

Nigel

Thanks Kevin and Nigel.

I'll give that a go. The previous websites I did a year back really fudged the database thing with source code control and the sites I'm about to prepare are more business critical. I see a couple of weeks' experimentation ahead and will review your resources.

Many thanks, Simon

So I followed the advice above and things have worked perfectly at the local end of things. uSync and uSync.ContentMappers do a grand job of saving every change I make.

My issue comes when I deploy to an Azure Web App with a "Publish" in VS2017. I set up a new Azure SQL Server and Database, apply the appropriate connection string to the publish settings and then the website switches to an installation page as shown below, and fails to progress further. Might I be failing to publish something to do with uSync?

Thanks, Simon

Hi

first time you need to seed your database - (so get umbraco to install it)

the quickest way to do this - is to remove the connection string compleatly, and blank the Umbraco Version in the app settings.

So remove UmbracoDSN line from connection strings and blank : <add key="umbracoConfigurationStatus" value=""/> in the app settings.

This will make umbraco do a fresh install (and if you db is clean) which will add all of the umbraco bits into the DB. once this is done uSync will kickin and do its thing and add all of your customisations and you will have a site.

Thanks Kevin - I'll give that a go.

Hi Kevin, everything works perfectly. The database seed that you mentioned was the key to success. I can now make changes to the site locally, on the local database and then publish the uSync files to see the update appear on the Azure Web App. uSync also commits to source code control, which is of course essential.

Thank you so much for your help (and of course Nigel too).

Best regards, Simon

is working on a reply...