A Git Source Control strategy for a live Sitecore website

Question

Firstly, I apologise for the sheer size of this question as I'm sure what I am proposing is a "big deal" in terms of implementing and probably could be three or four separate questions in itself. I wouldn't ask if I weren't in desperate need of help.

I have been given the monumental task of revising my company's risk management procedures in regards to our online work.

As we take no backups, nor protect our data I have decided that, like anyone involved in professional programming should already be doing, we were going to protect our work through source control. I currently do this on a local basis with Git, but others use no source control and ultimately we lose a lot of the benefits that source control offers. I'd rather us have a system where everyone uses Git and have it enforce the rule that if it's not in source control, it doesn't stay. Obviously, we're going to need a backup plan, but as a developer I suppose the first thing to do is to sort out the coding aspect of things before getting a backup solution sorted - obviously, any advice on that too is more than welcome.

We run a ASP.NET website with a SQL Server 2005 backend, running Sitecore as our CMS of choice. In an ideal world I would like to have all the changing parts of this CMS site under source control, including the database.

At the moment, and I know this isn't the greatest idea, I run one solution for ALL sublayouts built in Sitecore. This is under source control and thanks to Git I've been able to add branches and push new features and fix bugs easily (using Git-flow as my workflow solution). I'm still quite new to Git though, so I've not managed anything too complex outside of committing, ignoring certain files, etc.

On top of this, I would also like to use source control to get the database contents under source control. As I understand it, you can serialise Sitecore content items as a huge tree within the file system (saved as .item files if I remember correctly?). If this is the ideal solution I would also like to add these to source control, although I don't know exactly where they would be saved on the file system. My file system right now is like this:

- Data      (Logs, indexes, etc - is this needed to be in source control?)
- Source    (Helper files, although occasionally modified)
- Website   (Containing all the files I edit, and other essential Sitecore stuff)

As mentioned already my current repository is only on my system, and it consists of a single solution folder with a bunch of .ascx, .ascx.cs, .ascx.cs.designer and the odd .aspx file or two. This tends to make my life easier when uploading as, like with the

What I would like input on is an ideal way of managing this for all developers. Despite using a DVCS I would prefer to have the live server viewed as the main repository and for all the other developers to push and pull from it, and each other. We'll be using the git-flow workflow solution as it conforms to our way of development nicely. What I'm worried about, obviously, is setting this up correctly without destroying what's currently a very expensive, high-traffic site on a server with no backup.

Tips and advice on how much of the data on the server to stick in the repository, guidance on how to handle the serialised data in Sitecore and potentially how to use the source control itself as a way of backing up to a separate repository would be welcomed. This is the first time I've had to build a source control system/workflow for a live website, so any guidance and advice on what would be the best thing for me to do would be much appreciated.

---

EDIT: I am going to put a bounty on this to try and get more guides on how people handle Sitecore with Git.

To clarify myself, I am NOT looking for a way to back up my work, rather a way so that a number of developers can work on it and ensure that the code on the website is up to date with a central repository. For example, I have referenced before that I will be using git-flow to manage my workflow. The origin repo will exist on a shared server (which in time will likely be a test environment), and all developers will have clones of that to work on and to push to. From here, I want to be able to push changes from the origin repo on the shared drive to the live server and back again if errors are found. I would also like to include serialised content items in my repo.

Answer 1

Check out HedgeHog's Team Development Soultions (3.0 is latest version).It meets many of you needs when used with Visual Studio, Sitecore Rocks, Team City (or other build server). Visit http://hhogdev.com/ for more details.

Answer 2

Revised answer after revised question:

Ok, let me expand on my original idea now when we have more background information from you. Since you say that you only have once license for Sitecore and can't have a separate test server etc, we can always modify this slightly and still achieve the same effect.

What if you had several repositories on the same server running the live Sitecore? If it's possible for you to setup Sitecore to use different roots/repositories on the same file system, e.g. you change the url to http://yoursite.com/blahblah/test to run Sitecore in test mode. This depends on what kind of license you have of course, i.e. if it's tied to a specific machine. Anyway, this way you could test your site on another branch (e.g. a develop branch in a test repository) before you merge the stuff into master and let it go live.

So you could have a bare repository on the server, where everyone push and pull from. And you could have two additional non bare repositories on the same server, one with the master branch checked out and the other with the develop branch checked out. By logging in via ssh you can easily run "git pull" in the test repository if you want to test new functionality on the test version of your Sitecore site. When you are happy with the changes, merge into master and push to master on your bare repo and update the live repo in the same way.

I think you need to try and find a way to have two versions of your site, so you can test the changes before they go live.

---

Original post:

I strongly suggest that you have a separation between the live server and what you are currently working on, i.e. another repository where you push your work too (and pull from) which works as an integration repository. This way you can integrate code and test it locally (local to your organization) before you push it to the live server, so no one accidentally pushes code/databases/whatever directly to the live server.

I'd also recommend that you take backups of the data for the central repository, in other words, git should be used as a version control system, not as a backup system. Even git might fail and cause corrupted repositories, and then you are smoked if you don't have any backups anyway.

Also, if its possible, try to separate actual site content from the logic working on the data, i.e. try to keep a good model/view concept. This way you can easily setup a test environment with test databases that is independent of the code, and there is no need to commit databases. Unless you really want to commit them of course :)