Sitecore Continuous Integration Continued
Here’s an update on the post I wrote a year ago on our Continuous Integration project here at Pentia.
To put it short: it’s turned out to be one of the most successful internal projects in our company. In the last year we’ve added 20+ new projects into the system, and we are in the process of moving our old projects from SourceSafe to SVN, and creating build files for them.
Our setup is not a conventional build setup with specifically designed build scripts for a major project, it’s more of a build framework for the many Sitecore project passing through Pentia. We’ve designed our setup around our naming and location best practises, so in order to add a project to the build system, we only need to create a single file with about 10 lines of XML specifically for the project.
Our entire setup consist of:
1: nAnt build framework
This is a set of approx. 30 nAnt scripts which is shared across all our projects. The scripts handles everything from SVN, MSBuild, FxCop, deployment, zipped releases, automatic versioning and much more. The files are versioned so that changes and new features will not influence the older projects and break the builds. In the last year we have released 5 versions of the nAnt scripts.
2: Subversion version control
In my approx. 15 years of programming I’ve only worked with Visual SourceSafe as version control (and as those of you who knows the product knows, is hasn’t changed for 15 years either
, so the switch to SVN has been a daunting task for me. After a year, my only recommendation for those of you who consider it is to go for it! Subversion is easy to install and maintain (I recommend VisualSVN Server), easy to use (TortoiseSVN) and the integration into Visual Studio (VisualSVN) is perfect. Naturally the integration with nAnt is nice too as. E.g. it made it possible for us to automatically version our projects when releasing, by extracting the latest revision from SVN.
3: CruiseControl.NET
The hardest part to integrate into the company has been the CruiseControl.NET server. It’s not difficult to explain its purpose to the developers (to continuously check the projects on commits in SVN and build nightly releases), but the benefits of the other parts of the setup, for the individual developer has just been so much more evident. But still, its running, checking our builds and keeping our internal testing environment updated, by releasing each night.
4: Module library
The module library is a really neat feature of our build system. In short, it allows us to only maintain our own codebase in a project in version control and still allows developers to get quickly up and running, not making it necessary to install Sitecore version and thirdparty tools on their local machines. In the last year we’ve added 12 versions of Sitecore, 16 Sitecore modules (with 3+ versions each), 10+ third party modules like PDF, FTP and unit testing, and much more. The library allows us not only to add our old projects to the build system, but the cool thing is that when e.g. a new update to Sitecore is released, all our projects can be upgraded by changing a single line in the project build files.
5: Configuration merging
Both Sitecore and Microsoft has acknowledged the problem of mainting large configuration files. And the both have features which allows config changes to be merged from external files. The only thing they do not make easy, is to have different configurations for the different environments. For this we’ve developed a nAnt extension which allows the developers to create configuration merge files (configmerge files) which can be varied according to the environment we are building to. This has made a huge difference as opposed to juggling different configuration files for production/test/training/development environments for frontend and backend servers (6-7 web.configs!).
6: GUI tools.
We have lazy developers in Pentia
Joke aside, we quickly acknowledged that in order to successfully get the system to the developers, we had to provide them with better tools than the nAnt command-line and CruiseControl xml files. So we created a nice GUI for our nAnt scripts and for editing our CruiseControl server.
As you can hear, I am still pretty excited by the accomplishments we’ve made in the last year – and we have a lot of cool features waiting. Our next release will incorporate generation of SQL scripts for mounting Sitecore databases and setting up database access and automatic IIS setup. We also want to automate our releases even more, by generating batch files for folder security and automated FTP upload to the production servers.
I’ll still be happy to hear from anyone with experience or ideas – or you can give me or Pentia a shout if you want to hear more about our setup.




This is a very cool setup, – not very unlike the same setup we are using in Sitecore (I think somebody is working on a best practice for workgroups, that we might release). Anyway, this entire automated process has greatly improved our productivity.
While we do not have the same multitude of entire different projects as Pentia does, – we still work with several versions of Sitecore, and several modules.
The CruiseControl.NET tool has proved especially useful in the Sitecore case, as the nightly build results in a new version our testers continue with.
Suggestion (you might have thought of it already): Make sure to compile your unit tests belonging to the project as well. Then, after the nightly build, execute the unit test.
Very cool idea about the configuration files.
Thanks for an inspiring post about automated Sitecore development setup. Only thing I’m wondering; how do you deal with database changes, e.g. when a developer implements a feature which require new or changed Sitecore items? In Sitecore 6, item serialization is your friend – but what about projects implemented on former versions of Sitecore?
As you can read in this post http://mcore.wordpress.com/2009/03/17/sitecore-serialization-for-version-control/ there are some issues with serialization, so we haven’t integrated that completely yet.
At the moment all developers work on a local website, connecting to shared databases. When altering content, templates or similar we use a shared website on a development server to avoid data cache issues.