You are visiting the High Monkey blog archive. Posts prior to 2016 may not meet accessibility standards. Please visit our current blog area at https://www.highmonkey.com/blog to view accessibility compliant blog posts published since January 1, 2016.

Kentico's Continuous Integration

Written By: Virgil Carroll
Posted: 1/20/2016

Although the release of Kentico 9 has shown us multiple improvement to the Kentico CMS and EMS there is one piece in particular that I want to highlight in this blog post, Kentico’s new continuous integration feature. In this post I will give readers a high level understanding around setting up Kentico’s continuous integration as well as walking you through my setting up a site to use this functionality.

Setting Up Continuous Integration (CI) in Kentico:

Something to understand up front is that the Kentico Continuous Integration is best set up when doing the initial install of your site, if you don’t you may cause yourself a lot of work down the road trying to plan the right breakpoint in which to run the CI routines.

Prior to setting up CI, there are a couple of things that you need to be sure are set up properly in order for this feature to function correctly (and these things are not noted in the Kentico documentation).

The first thing is you need to make sure you have the correct file permissions set up on the App_Data folder in the CMS directory.  This will often be your application pool account (in this case we are using Network Service) in IIS and it needs the ability to modify files in the CI Repository folder (which resides in the App_Data folder).
 
The second thing you want to make sure is you have more than adequate disk space on the hard drive where your site is located.  When you run CI for the first time, all the serialized XML files will be stored in the CI directory for synchronization.  Where for small sites this will not be much of an issue, when you deal with sites like HM does, we are often creating 1000s and 1000s of sync files over the life of a project, which may end up taking up a significant amount of disk space.

Once you have everything in place, your first step in the process is to enable CI in your environment.  You can easily access the CI administrative functionality from the admin menu.

Screen shot of kentico applications / continuous integration

Once there, check the ‘Enable Continuous Integration’ and click the ‘Save’ button at the top.

Continuous Integration is now turned on.  

Screenshot of kentico continuous integration

To begin utilizing its features, you must first serialize all the objects from the database (basically making an initial representation of these files in XML).  You accomplish this by pressing the ‘Serialize all objects’ button.  This will pop-up a second screen where you can watch as all the objects are processed.  You will see that even in a small site deployment, many files will be created to keep the entire Kentico system in sync.

Screenshot of Kentico serializing objects

During the initial serialization, a folder is created for each class of object in your system.

Screenshot of file folders

Inside each class folder are XML files that are created to represent each object.

Screenshot #2 of file folders

As changes are made to your environment, these class objects are updated (and new ones added) which represent the changes to make to another system once synced.

Code

The part I really like about this, is its actually quite easy to see what objects have been created and updated.  I have found this useful to be able to understand how changes are tracked and potentially modified, so I understand what I want and don’t want to sync going forward.

BUT once this process has completed, you now have continuous integration setup on your machine.

To setup your other machines to participate in the CI process, it is recommended that you take a copy of your web site directory and database once your CI object initial serialization process is complete.  Use this copy to set-up your local system so that all systems start out at the same ‘footprint’ in the process.  You could add another machine later in the process, but overall most likely you are going to set these up at the start of your project to keep them in sync over the entire lifecycle.

Using CI to stay in sync:

Now that you have continuous integration setup, you will want to use this to keep your combination of instances in sync.  How you use this is completely dependent on your team’s requirements, but probably the most typical use is going to be across a team of developers where you have one main install for overall testing and duplicate copies on developer machines to do work.

Disclaimer: if your development team is smaller and undisciplined, this functionality may not be worth the effort for you.  To use CI well, you really need a team where developers need to stay in constant sync and you have a solid build process to integrate with.  Where I am sure there are other practices where CI could help out, discipline and a methodical approach will be critical to success.

Before I start walking you through using CI, the first thing you need to understand is when it is active…any change you make to your environment, whether adding a new page or page type, adding a new item to a form, or even adding a widget onto a page, are tracked by the CI functionality and the changes are stored in the XML structure.   So make sure first you want to track all of these changes.
 
Where it might be useful to track them all, there are instances where you might not want to do this.  For a recent project we are working on, we ran into good example.  In this project, the client had overall 14,000 image files we were bringing into the new Kentico 9 build.  In this scenario, where we need to manage these images in Kentico, we did not want those to be serialized and transferred to our developer’s machines (though we still wanted to store it in our remote code repository).  Kentico luckily gives us the advanced features in the CI configuration file (stored in the CI directory) to exclude directories, file types or any related scenario from being included in the CI process.  You can find more information about this here: https://docs.kentico.com/display/K9/Setting+up+continuous+integration#Settingupcontinuousintegration-Filteringobjecttypes

I will give you one word of warning on this from my own personal lesson learned, make sure you determine you want to exclude these files before you add them, because the CI serialization process runs immediately and constantly and it’s a lot harder to back those changes out afterwards.

Once your changes have been saved to your local system, the next step is to use some kind of process to sync this instance with an instance on another machine (often using a testing system as the master and developer systems as the consumers).  The most practical approach for this is to use some form of a remote or local code repository.  Where it is beyond the scope of this post to recommend what you should use, we are currently using Bitbucket and have been very happy with it.

Below you see one of our SourceTree installs (a program specifically built for Bitbucket but can be used with other GIT-type repositories) after a synchronization job was completed.  You will also note how you can see the CI XML files that were synced as part of the process.

Screenshot of data

Once you have synced remotely (push), you will sync again to the local instance you want to update (pull).  It is important to note that you do not need a code repository to do this, but you will need some standardized way to discover the differences from the master CI directory and the other systems so you only move those XML files that have been updated or added to finish the integration.

Once you have synced down the new / updated files, you are ready to complete the CI process.  This is where I actually get a bit excited about the process because we get to use something that I have wished for a long time we could use more with Kentico…PowerShell.  Coming from the SharePoint world, I use PowerShell for almost every administrative task I do, so I am sometimes disappointed I cannot do the same with Kentico.  Where that has always been the case before, fortunately the Kentico team is starting to see the light and decided to provide the CI sync as a PowerShell process.  In running this sync, each change made since the last sync will be read then added or updated in the local Kentico instance to match the source exactly.

To start this process, Kentico has been nice enough to not only provide example PowerShell, but actually provide a downloadable .PS1 file to use.  Below you can see this file, which is downloadable here: https://docs.kentico.com/display/K9/Restoring+continuous+integration+files+to+the+database

Screenshot of code

You will notice that much like the Kentico installation and upgrade process, this PowerShell file sets your App_Offline file and shuts down any external Kentico services to complete the process.  This is important to make sure that during the restore people are not actively changing items that may be updated and causing significant issues.

Once you are ready to go, open this file in a PowerShell window and enter the path to the local Kentico directory you want to update.

Screenshot of code

After starting to run, note that if the process is working, you will see a list of objects that are being updated.

Screenshot of code

Once the process has completed, you will see the final command of ‘Optimizing file repository…’ and again be at the command prompt.

Screenshot of code

You have now synced your CI changes, restoring them to your local copy database and should be able to load up the site and see all the updates and additions immediately.

How Continuous Integration can help you and your team:

When looking at the new Kentico 9 Continuous Integration, there are some true benefits when it comes to using it for your organization. Being able to keep multiple systems on the same page during the lifecycle of a development / design project can give you the assurance that your entire team is working with the latest information and building a consistent overall experience. Where overall tailored towards true code developers, I actually believe this could also be very useful to use with your design and content team during initial development to allow them to work independently yet not stray too far away from the overall site direction.  I am truly excited about this recent feature from Kentico and look forward to using it in the future!


 

Chad's Bio Coming Soon!

More About Virgil

Virgil Carroll is the owner and president of High Monkey – based in Minneapolis Minnesota. Virgil also wears the multiple ‘hats’ of Principle Human Solutions Architect and SharePoint Architect.

Virgil is one of those rare individuals who can dive deep into technical topics while speaking clearly to the business owners of a project and never forgetting that the end user experience has the highest priority. He calls it using both sides of his brain. Virgil is passionate about leveraging technologies ‘out of the box’ as much as possible with a focus on the strategic use of content to create websites that deliver the right content to the right audience on the right device at the right time. Virgil brings high energy, an ironic wit, and a sense of grounded perspective whenever he speaks to an audience. Virgil regularly speaks at conferences and user groups throughout the United States and occasionally in Europe.

Posted: 1/20/2016 12:00:00 AM by Brian Haukos | with 0 comments