Best practice for sandbox / production environment
Hi guys,
I have been working on my first bigger Umbraco site for a little while now and have run into some problems that I am not sure excatly how got started.
Basically my Umbraco installation broke! But to be fair, I probably didn't treat it very nice. The site isn't in production yet so no panic here, but I have had a production site and a development site, that both used the same database. This I quickly learned was not that good an idea, but to work around it, I would copy all of my IIS site file contents between the two when needed.
At the same time I have had a three different root sites, but only one published. The three sites have had clashing names of documents, and when I decided to do a little spring cleaning and delete the two sites that were not published and no longer in use, it all broke and I couldn't publish anything new.
I know that this is a big mess, and I am not trying to clean this up. I have started a new clean Umbraco installation, and have all of my user controls etc. handy for redeployment, so it should only take a days work to recreate everything manually.
But my question is... in what way should I seperate my development (sandbox) and production environment? How should I move what I have in my Sandbox into production? I have my sandbox on my own computer and use do debugging with Visual Studio 2008, while I have my Production site on a Windows 2003 server with IIS 6.0. I would like my sandbox to be as close to my production environment as possible, and be able to easily "move" stuff into production.
Is there a best practice for doing this?
My next site will most likely include two developers, who are not in the same geographical location working on a site at a third location without VPN. We will be working from the same Team Foundation Server on the same User Control projects, and testing them on the same site preferably. Any thoughts on how to that?
I have two developer umbraco instances which use separate umbraco dbs. There, developers are free to create whatever they need and they dont collate with each other. However, there are some files that have to be merged between developers and we keep them under SVN. Those files are usually umbraco files that you modified in some way, or some custom directories/files that you created during development. Anytime you modify some umbraco file, make sure you add it to repository, so others can relate to modified version. We call this repo: merge-sensitive :)
For example, list of stuff that we keep under svn is:
/config
/css
/images
/masterpages
/umbraco/config
/umbraco/images/tray
/umbraco/js/umbracoDefault.js
/xslt
/web.cofig
Other than that, you have to make sure all the assemblies you develop go to /bin and all usercontrols go to /usercontrols, which we achieved with MSBuild. Of course, both developers keep the code under svn.
When it comes to deploying to production, there are couple of options we use depending of how big change is.
We usually setup Staging environment first to collect all developers work together, and make sure it works with production umbraco db.
Staging environment should be composed of umbraco files from Production updated/merged with changes from you merge-sensitive repo.
There you see which changes has to be made to production, and make a note of all of them. Then you try to update production with needed changes, which is up to you how you gonna do it. Either, replace the whole db (which is not so recommended, but could work because you got it from production first, so all data is in), or you could use fabulous functionality of umbraco packages (package actions are pretty cool feature that you can extend with you update logic as well).
Best practice for sandbox / production environment
Hi guys,
I have been working on my first bigger Umbraco site for a little while now and have run into some problems that I am not sure excatly how got started.
Basically my Umbraco installation broke! But to be fair, I probably didn't treat it very nice. The site isn't in production yet so no panic here, but I have had a production site and a development site, that both used the same database. This I quickly learned was not that good an idea, but to work around it, I would copy all of my IIS site file contents between the two when needed.
At the same time I have had a three different root sites, but only one published. The three sites have had clashing names of documents, and when I decided to do a little spring cleaning and delete the two sites that were not published and no longer in use, it all broke and I couldn't publish anything new.
I know that this is a big mess, and I am not trying to clean this up. I have started a new clean Umbraco installation, and have all of my user controls etc. handy for redeployment, so it should only take a days work to recreate everything manually.
But my question is... in what way should I seperate my development (sandbox) and production environment? How should I move what I have in my Sandbox into production? I have my sandbox on my own computer and use do debugging with Visual Studio 2008, while I have my Production site on a Windows 2003 server with IIS 6.0. I would like my sandbox to be as close to my production environment as possible, and be able to easily "move" stuff into production.
Is there a best practice for doing this?
My next site will most likely include two developers, who are not in the same geographical location working on a site at a third location without VPN. We will be working from the same Team Foundation Server on the same User Control projects, and testing them on the same site preferably. Any thoughts on how to that?
/RasB
Hi,
check out this thread - it should answer some of your questions: http://our.umbraco.org/forum/core/general/3619-Source-control-and-multiple-developers
Hi RasB,
I can just share my own practice:
I have two developer umbraco instances which use separate umbraco dbs. There, developers are free to create whatever they need and they dont collate with each other. However, there are some files that have to be merged between developers and we keep them under SVN. Those files are usually umbraco files that you modified in some way, or some custom directories/files that you created during development. Anytime you modify some umbraco file, make sure you add it to repository, so others can relate to modified version. We call this repo: merge-sensitive :)
For example, list of stuff that we keep under svn is:
Other than that, you have to make sure all the assemblies you develop go to /bin and all usercontrols go to /usercontrols, which we achieved with MSBuild. Of course, both developers keep the code under svn.
When it comes to deploying to production, there are couple of options we use depending of how big change is.
We usually setup Staging environment first to collect all developers work together, and make sure it works with production umbraco db.
Staging environment should be composed of umbraco files from Production updated/merged with changes from you merge-sensitive repo.
There you see which changes has to be made to production, and make a note of all of them. Then you try to update production with needed changes, which is up to you how you gonna do it. Either, replace the whole db (which is not so recommended, but could work because you got it from production first, so all data is in), or you could use fabulous functionality of umbraco packages (package actions are pretty cool feature that you can extend with you update logic as well).
Hope it helps..
Hey guys,
Awesome input! I will try to figure out what works best for me.
/RasB
is working on a reply...