Sitecore

Continuous Integration and Sitecore


We have recently launched our internal Continuous Integration environment for use in our many Sitecore projects. The setup is pretty straightforward with NAnt, CruiseControl.NET and Subversion in beautiful harmony. Because of the integration with Visual Studio, we would have liked to use Visual Studio Team System, but the pricing deterred us. When nAnt, CC.NET and Subversion are so cool why on earth has Microsoft set their price so high? In my view, they could have cornered the entire .NET based market by having a more relaxed price policy.
Well back to the point: We have tried to implement an environment which helps our developers and increases productivity, by removing some of the mundane tasks of developing in Sitecore. I am real excited about the prospects, so I would like to share some of the cool features we’ve implemented:

Module Library:
We have collected an entire module library, including all newer version of Sitecore, all Sitecore modules as well as all our internal modules. This means that when starting a new project, or when implementing a new modules in a project, the customer merely points the build configuration to which modules the project uses, and – hey presto – the module is included in the project. This includes code files, Sitecore packages, configuration file changes (see later) and all other related files. The point is – the project points to a module, and the module is responsible for integrating itself in the project.

Configuration files management:
We have previously had a lot of hassle trying to maintaining changes in the Sitecore web.config as well as all the other configuration files. Trying to keep all config files in all project targets (dev, test, prod, etc.) synchronized is a pain. Therefore we have developed a nAnt task which when running the build, merges project/module specific changes into Sitecores standard configuration file. I.e. when a full build is run:

  1. The standard Sitecore configuration files are copied from the Module Library (from the correct version of Sitecore)
  2. The relevant Sitecore modules standard configuration changes are merged into the configuration files
  3. Dependant on which target the build is for, the project specific configuration changes (connection strings etc.) are merged into the configuration files.

A side from keeping the configuration files synchronized, this also means that when upgrading Sitecore (a task which basically to point the project to the new version in the module library) all Sitecore’s new or changed configuration settings are automatically included.

Our CI environment also implements Subversion, MSBuild, FxCop, automatic test server deployment and installation versioning/packaging.
One of the problems we are facing with Sitecore and CI is the amount of functionality and configuration hosted in the Sitecore database. We’ve through hard about e.g. integrating the Sitecore packager with the build environment, but dropped the idea. Please let me know if you’ve done something similar.
As you can hear i’m pretty excited about this, and would really like to make it as cool as possible – so throw me a comment if you have experiences with CI/build environments and Sitecore.

Standard

3 thoughts on “Continuous Integration and Sitecore

  1. todd says:

    Where did you get with this? I am about to enbark on a similar project. In fact, I did the same as you with an EPiServer project and wrote a msbuild task for xml config merging to the same job (it is a specialised type of merge).

    • Eldblom says:

      We’re using this with great success. Most of these types of setups focus on continuously integrating major projects, thereby limiting the number of man made errors. Our focus in the first part of the project (which is now well over), has been more on the concept of build configuration, i.e. automating the manual tasks in a project when building, testing, deploying etc.
      Furthermore, we are focused on supporting a large quantity of projects (we currently have 30+ project running in our environment – all Sitecore) and therefore ease of setup and configuration is key – as well as all our developers (20+) being able to customize each build config for each projects setup.
      We are continually adding features to the setup (CSS/JS minification, Sitecore server configuration, batch file generation, extended CI support, etc.), and it is now a super vital part of our whole developement process.

Leave a reply to Attila Horvath Cancel reply