Sitecore With Continuous Integration and Deployment

Nowadays, release to different environments is performed using Continuous Integration and Continuous Deployment.  This process allows for a Quicker and Quality production deployment.

First, let see what does Continuous Integration, Delivery and Deployment means

Continuous Integration (CI)

It is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Continuous Delivery

It is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently.

Continuous deployment

It is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically.

During this post, I will be explaining an architecture of the CI and CD for Sitecore. Below is a diagram showing the different process and steps for the CI/CD to work:

Capture

Development Team to Code Repository

This is the first step during which developers will push their code to the repository (BitBucket, GitHub). When you are ready for deployment, you just need to click on the button to start the process.

CI Server

During this phase, the code integration is performed. In this architecture, I am making use of Jenkins. Jenkins can be used as a simple CI server or turned into the continuous delivery hub for any project. You can schedule the build, trigger it manually or start when there is a change in the Code Repository.

You may define different pre-requisites and post-requisites. For example, on success, trigger the package generation of assemblies.

When build is completed and is a success, the nuget package is generated and versioned before uploading it to the artifact repository automatically. An example of the Artifact Repository is ProGet. The nuget package contains the assemblies that needs to be deployed to the different Environments.

As soon as the package is uploaded on the Artifact Repository, a request is sent to the Octopus Deploy Server to trigger the deployment process. Once the deployment request is received at the Octopus Deploy Server, it will fetch the nuget package using the version number from the Artifact Repository.

The way Octopus Deploy works is as follows: it has different tentacles which are configured on the different servers. When code is pushed to a Cluster, the code gets deployed to all the servers which has a tentacle configured as shown in the diagram below:

Tentacles.PNG

The code will deployed to only Server 1, 3 and 5 because the tentacles have been configured only on those servers.

After retrieving the Nuget package, the package is deployed to the target environment. Once the deployment is completed, you can have your automated testing to run. You can make use of PowerShell Scripts to be executed after each process.

The above explanation is mostly for assemblies. But what about Sitecore Items? Only a small change is required.

Using TDS, you can easily serialize the items from the Sitecore Instance and then push the items to your Repository. From here, you may make use of Sitecore Courier to create your sitecore update package. Then the same process is applied as above:

  • Push the package to the Artifact Repository.
  • Trigger the deployment on the Octopus Deploy Server

A sample of the amendment of the diagram is shown below:

TDS.PNG

The Sitecore Courier is setup on the CI server in order to be able to generate the Update Package before pushing it to the Artifact Repository.

In order to install the Sitecore Item Update package, you will need to make use of the Sitecore Update Installation Wizard. This feature is already installed when creating the Sitecore Instance.You can access the Update Installation Wizard using the path: http://[domain]/sitecore/admin/updateinstallationwizard.aspx

You have 2 options to install the Sitecore Update Package:

  1. Use Sitecore Ship
  2. Implement a WebService that call the Update Installation Wizard method to install the package.

The use of PowerShell Scripts make the automated deployment more flexible. After the installation of the Sitecore package, you can make Octopus Deploy to trigger the Auto Publish agent. A sample code is shown below:

[WebService(Namespace = "YourNamespace")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ScriptService]
[ToolboxItem(false)]

public class CIPublishing : WebService
{

    [WebMethod]
    public string TriggerPublish(string agent)
    {
        var node = Factory.GetConfigNode("scheduling/agent[@name='" + agent + "']");

        var publishJob = Factory.CreateObject(node, true);

        var publishMethod = StringUtil.GetString(new[] 
        { 
            XmlUtil.GetAttribute("method", node), "Execute"
        });

        var jobOptions = new JobOptions(agent, "[CI] Publishing", "Shell", publishJob, publishMethod, new object[] { })
        {
            ContextUser = Sitecore.Context.User,
            AfterLife = TimeSpan.FromMinutes(5),
            WriteToLog = true,
        };

        JobManager.Start(jobOptions);

        return "200";
    }
}

Quality of Code

Code quality is very important especially if you are building a large site. You can make use of Sonar Qube. It will analyze the code and provide reports on the dashboard or share it via email. Once the code is retrieved from the Code Repository, you can then have a step where the Code Quality Process needs to trigger as shown below:

With Sonar.PNG

Tools Used

Name Pricing Website
TDS Paid http://www.teamdevelopmentforsitecore.com
SonarQube Free http://www.sonarqube.org
Jenkins Free https://jenkins.io
ProGet Paid http://inedo.com/proget

References

  1. https://www.thoughtworks.com/continuous-integration
  2. https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s