Basically this post is a recap of the “Sitecore and Continuous Integration” webinar, with some extra details about certain topics.
The goal of continuous integration is to push every little piece of new software to next environments, the last step being production. Along this way, you want your software to be merged, compiled and tested.
This way of developing has been around for a while with standard ASP .NET software. The problem with Sitecore is that it also heavily relies on the database to function. Source control of the database is possible, but can be a deviant complex task. Some guys at Hedgehog developed TDS, a licensed solution for all your Sitecore collaboration problems. This isn’t a option for everyone however, and you maybe want a more simple cost free solution.
Make sure you install Sitecore Rocks before you continue. Watch Pieter Brinkmans webinar if you never heard of Sitecore Rocks before.
VS Project structure
You want your project to be easily shared and deployed between developers. Here are some tips:
- Every developer has his own “dirty dev” web, master and core database, best not to use a shared database for development, as you will get in each others way.
- Create a different folder for your sitecore libraries and let VS copy them to the bin folder on each build.
- Use a App_Data folder in your VS solution for your sitecore data folder. Make sure you give this folder the required rights! More on ASP.NET folder structure can be read here
- In your web.config file, set a relative reference to App_Data in your datafolder variable.
- Make separate config files for each environment you are going to use.
- Also make separate ConnectionString.config files, unless you use the same settings on each environment.
- (Optional) You may want to consider removing the Sitecore shell from the project, depending on how badly you want use it in your development environment. Also, source control systems aren’t comfortable with large volumes of files. If you do decide to remove it, make shure you leave the Sitecore Rocks webservice intact.
Sitecore Item Version Control
First, make sure you have a folder called “serialization” in your App_Data folder. This is the folder where our sitecore items are put into text files.
Use Sitecore Rocks to serialize the items you want to share. To do this, rightclick the node of the tree and go to Tools/Serialization/Serialize Tree. Do not put the entire sitecore tree in there, just the necessary like templates, content and media. Now that you have the files on disk, you can commit them to the rest of the team.
Synchronize your serialization folder and perhaps the rest of the project. Now just click one of the Update options in the serialization menu and voila, your items are updated!
Automated Building and Testing
This is something that depends on your own preference, methods and project conditions. The idea is to have a different environment with a Sitecore Instance(with shell perhaps) that checks out the latest version of the application of the source control server. The application is then build and tested if you have unit testing. Some options for these are:
- Out of the box building and testing if you use Team Foundation Server.
- NAnt, NUnit
- CruiseControl.Net / Jenkins
I personally use Microsoft Web Deploy to do this. You can deploy directly from Visual Studio as well as a build server. I used this article to set everything up.
Setting up continuous integration for Sitecore can take some time to perfect, but you will find it very productive once all the little daily frustrations are gone, making time to concentrate on building better websites.