Enterprise Sitecore: Continuous Integration & Configuration Management

Oshyn employs a rigorous test-driven development process and continuous integration that allows development to be done with greater transparency, greater efficiency and greater predictability. This diagram describes the Oshyn Sitecore Development & Configuration Management Methodology.

The process is as follows:

1. Unit tests created using NUnit in Visual Studio IDE

2. Code written in Visual Studio

3. Code tested

4. Code checked to Subversion

5. Ad Hoc deployment to Development site (on Developer’s desktop) to see working templates and code

6. Hourly release to Integration site

7. Developer notified by Hudson of any build errors related to their code

8. Content released from the CMS

9. Code deployed to QA site and tested

10. Code deployed to Staging Site and verified

11. Code deployed to Production

Hudson Deployment

Hudson is a Continues Integration Software that has the capability to update, build and deploy source code periodically.

In this section, let me explain the cycle that Hudson does for the compilation and deployment of a Sitecore site. Please refer to the following diagram:

1. Hudson performs an SVN update from the repository. The code is downloaded into the Hudson machine in order to compile it. Hudson has an SVN plugin that can perform these actions and can be configured from the Hudson Job.

2. Hudson can be integrated with NAnt. Hudson calls a custom NAnt script to compile the .NET code and create the necessary dlls. To accomplish that, you need to configure in Hudson machine the NAnt task “Contrib”.

3. NAnt script can uses NUnit task to execute unit tests. So in this step, NAnt execute the Test Cases over the code. If Test fails, the execution of the build is going to fail; otherwise the deployment is going to be executed.

4. NAnt has an FTPTask that can be used for FTP deployments. This task like the Contrib task needs to be configured and installed on Hudson Machine. This Nant Task is the one in charge of the deployment of the compiled code to the IIS server where the application lives.

The above process is a real sample of how we can use Hudson to deploy a Sitecore Application in general terms. Now let’s consider the following SVN structure:

/trunk
/trunk/Code/WebProject
/trunk/Code/Solution/ Solution.sln
/trunk/default.build
/tags

Where WebProject is the folder representing a C# Web project included in the solution file Solution.sln, and the file default.build is the Nant Script that Hudson calls to update, compile, and deploy. Suppose that you want to use the same mechanism to deploy the same code but using different configuration files according to the environment. Your NAnt script needs to receive an additional parameter that represents the environment to deploy and also you need to create a Configuration Manager folder in your SVN like the following example:

/trunk/ConfigurationManager
/trunk/ConfigurationManager/BuildFiles/defaultParameterized.build
/trunk/ConfigurationManager/Environments/WebProject/Web.format.config
/trunk/ConfigurationManager/Environments/WebProject/Integration/EnvBuild.property
/trunk/ConfigurationManager/Environments/WebProject/QA/EnvBuild.property
/trunk/ConfigurationManager/Environments/WebProject/PROD/EnvBuild.property

Notice that the default.build file has been renamed and moved into the configuration manager folder structure, so Hudson needs to use this build file instead of the older one.

The idea of this structure is that the same Web.config can be used for all the environments but with specific changes according to the environments like urls, etc.

For example suppose that your EnvBuid.property has a defined property like:

<property name="debugValue" value="true" /> for Integration, QA, and for production the value is “false”. Nant is going to replace this token into the file Web.format.config depending of which environment is under build. So the File Web.format.config should have a definition like <compilation defaultLanguage="c#" debug="${debugValue}">.

Following is the complete process that the NAnt script needs do and a sample script tested with NANT 0.9 that can be used as a template for this proposes:

1. The NAnt Script receives parameters about the Solution File Name, Project Name, Web.config file (destinationfile), property file, Environment Tag, Web.format.config(destinationfile). FTP information like server, user, password, ftpsource folder, and ftp destination folder. Notice that the parameter “environmenttag” means the environment under compilation like Integration, QA or PROD.

2. According to the parameters “environmenttag”, the process includes the corresponding EnvBuild.property file.

3. Apply and replace the properties into the file Web.format.config.

4. Rename the file Web.format.config to Web.config and copy inside the project location.

5. Compile the code.

6. Run Unit tests. Note that this section is showed in the script but not the implementation. For more details please check http://nant.sourceforge.net nunit2 task.

7. Deploy to the IIS server the Web.config and necessary dlls. Note that this example has a simple mapping to deploy only the Web.config files. You can add all the put tags that you want.