Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • ssougnez 46 posts 189 karma points c-trib
    May 17, 2018 @ 23:25
    ssougnez
    0

    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

  • Nigel Wilson 851 posts 1822 karma points
    May 22, 2018 @ 00:03
    Nigel Wilson
    0

    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

  • ssougnez 46 posts 189 karma points c-trib
    May 23, 2018 @ 18:41
    ssougnez
    0

    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?

  • Nigel Wilson 851 posts 1822 karma points
    May 23, 2018 @ 19:46
    Nigel Wilson
    0

    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

  • ssougnez 46 posts 189 karma points c-trib
    May 23, 2018 @ 21:28
    ssougnez
    0

    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.

  • Nigel Wilson 851 posts 1822 karma points
    May 23, 2018 @ 21:50
    Nigel Wilson
    0

    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.

Please Sign in or register to post replies

Write your reply to:

Draft