.png?width=667&height=667&ext=.png)
How Compare For Kentico Works - Part 1
Introduction
This past week BizStream launched a new product targeted at Kentico developers, Compare for Kentico. We have been very excited to do so because we believe that Compare for Kentico makes Kentico deployments easier, quicker, and more accurate. We strongly believe this because we have been using the tool internally for quite some time. In fact we have had almost a year to take this tool from a concept, and cobbled together set of functionality, to production worthy. We started with using it on just a few test sites, and are now happily using it to make deployments easier on our client's sites. Our development team loves it, and we think you will too.
With that being said my goal of this blog post is to do a deep dive on using Compare for Kentico to visually compare two different Kentico website instances to show you how it actually works. Keep reading to find out how you can cut your deployment time, be more confident that the deployment actually worked, and keeping some of your own sanity intact when it comes to moving changes from one environment to the next.
Why Did We Make Compare for Kentico?
Let me take CI first. Kentico 9.0 introduced an amazing new feature when it came out with Continuous Integration. CI does a great job of allowing developers to develop their websites faster in a team environment. It allows developers to interact with Kentico database changes as if they were filesystem changes that their source control repositories (TFS / GIT / etc. etc.) can easily handle. This allows for automated code sharing and deployments from Dev to QA. However, it is not really targeted at helping developers migrate content changes from QA to Production where source control repositories are not normally in play (from the content side anyways). Plus CI does not know about every single thing possible in the asp.net web application and SQL database that powers a Kentico site.
Next is the Kentico Content Staging application. This tool does indeed help push changes from any type of environment that you configure it for, and it is extremely useful. We use it all the time to sync changes from QA to Prod or Dev to QA at BizStream. However, Kentico veterans know that when using Content Staging and its great power, it also comes with great responsibility. Content Staging is a tool that we like to see as a "blind overwrite" scenario. That is to say that staging has no idea if one developer touched a page template in Prod, made changes, and did not make those changes in QA (bad! bad! developer!). If you click the Synchronize Selected button it just takes whatever you have in the source environment and pushes it to production. Also Content Staging only works with certain database objects in Kentico, and not files in the filesystem.
As you can see, even in a pure deployment scenario where you do use CI and Content Staging together, there are still a few gaps that sometimes make deployments a nightmare. Most of the time you had to rely on a developer and content admin working together to make sure that a large deployment went off without a hitch. And let's be honest, even then sometimes it still feels like you end up in a situation where you are crossing your fingers at the time of deployment, and saying "Hold on to your butt's, here we go".
All of the above issues are multiplied when you have more than one development team in play on a project. I have been involved in many large Kentico projects that require the client have their own set of developers, BizStream has developers involved, there might be a third set of SEO workers, and a fourth set of content admins all working at the same time in a staging environment. Changes are happening fast and furious, and there might even be more than one development project going at the same time that are all working on different deployment schedules and timelines. All of this to ensure the mighty deadline is met, and stakeholders are happy. Oh, and don't forget the pesky project managers who are probably pushing to have training done in the same environment at the same time too. Isn't our job fun ?
Having this challenge over and over again was our primary motivation for creating Compare for Kentico. We got tired of having an out of sync page template here, or missing web part property there. We wanted to know the situation better before the deployment actually happened. We believe our tool does just that.
How the Heck Does it Actually Work?
Compare for Kentico is packaged up and delivered as custom Kentico Module. Once you sign up for an account at our website, you are given access to a zip file and serial number. You can simply download the zip and install the module the same way you install any custom Kentico module in Kentico. We thought it made a ton of sense to keep our product within the same boundaries and methodologies that Kentico has already created. Why re-invent the wheel right? Plus by creating a custom module we get to re-use the built in user interface, data classes, and code generators that Kentico modules come with.
You start by installing the entire product in a Kentico 8.2 site. The main part of the installation is what we refer to as the tools module. This module is what we like to think of as the "brains" of the operation. It is where you register the serial number, register sites for comparison, and where you create projects to compare two sites at the same time. Anyone familiar with Kentico modules should notice the setup and configuration is much like the other built in modules in Kentico. There are vertical tabs that allow you to switch better sites, projects, and settings. The tool should walk you through the initial setup process to register your first two sites as a project fairly automatically.
During the process of registering a site, you provide the URL to what that site is. Compare for Kentico will try to reach out across a secure connection to that site and see if the companion module or "agent" is running on that site. If the tool detects Compare is running on that target site, you can simply authenticate, and will be good to continue. If the tool can't detect the agent on the target site, it prompts you for installation. Again we tried very hard to make this as easy as possible. One of our favorite aspects of this architecture is that it does not require a VPN connection, firewall hole, or other creative network hack to talk from one Kentico site to another. We all know that working locally on our own workstations is more comfortable than trying to work on a remote connection.
Once you have the main tool installed and agents running on your two sites that you want to visually compare, you join them as a project. Each project has a run compare button available that initiates the comparison. Once the compare button is clicked, the product will reach out across the secure connection and enumerate through everything it can on each site. And when we say everything, we mean it. Our product will bring back the details on every file in the filesystem, every database object in the SQL database catalog, and every Kentico specific object (that the Kentico API supports) in that site. That information is then sent back to the main tool from both sites you are comparing, and we can then show you the results.
Conclusion
Part 2 of How Compare for Kentico Works is up next. In the second part of the series, we will go into more on setting up sites for comparison, custom filtering of Kentico objects, the end result of the comparison, and how BizStream uses the tool.
