When you're developing a website or application, your workflow will usually include at least three environments. If you’ve worked with OpenText Web Site Management Server (RedDot), you're probably familiar with the challenges of keeping multiple projects synchronized – it can get chaotic, to say the least.

We recently launched a new website for Mackenzie Investments. It involved several distributed teams collaborating on development, integrating our pieces of the application, and then releasing to the client for user acceptance testing. Our workflow involved as many as eight CMS projects across multiple OpenText Web Site Management Servers, with for-launch and post-launch branches. These projects included:

• CMS development
• Integrated testing
• User acceptance testing (UAT)
• Production

The CMS development was done separately, maintaining the stability of the other environments. Features and bug fixes were released every two weeks, and each team would push their code to the integrated testing environment. After integrated testing, the code would be released to the client for user acceptance testing and production, if the release was recommended for promotion.

The challenge of keeping track

The typical methods of updating content classes between multiple web projects are:

• Using content class sharing, exporting each template from the source project and importing it the target project,
• Copying and pasting code between windows and remembering to create any missing or modified elements.

Since we were using multiple CMS servers, exporting and importing or copying and pasting were our only options. With 310 different content classes and several CMS developers working in parallel on different components, it’s easy to see the challenge of tracking the changes between releases and eliminating user error when deploying the changes.

RedDot Query Language (RQL)

A strength of OpenText Web Site Management Server is its web service and comprehensive programming interface called RedDot Query Language (RQL). This lets application
execute RQL commands against the CMS to do anything a user can do manually, from creating a content class and elements to creating a page and populating content.

Here at Yellow Pencil, we developed a .NET RQL library, an object-oriented command set of RQL commands, which it made it possible to perform complex operations with a small amount of self-documenting code. We used our library to create Script Runner, a Visual Studio solution for batching and scripting changes and deploying them to any environment.

That meant our CMS developers could work in Visual Studio’s familiar interface, updating content class templates with code completion and syntax highlighting. Creating and updating content classes, creating elements, and even populating pages with content could be scripted with a few lines of C# code.

Script Runner had five immediate benefits:

Repeatability: Using a scripted approach, the same change could be automatically deployed to multiple CMS environments. This saved time and was far less vulnerable to errors than a manual process.

Documentation: All changes were comprehensively documented by the scripts themselves. By reading the script source code, any web developer could gain a full understanding of what changes are being performed on the CMS.

Automation: It was feasible to make changes to the CMS that would otherwise require enormous manual effort. For example, it was possible to write and execute a script that applied a change to tens of thousands of CMS pages in only a few hours of unattended execution time, whereas the same change would have taken months of man-hours to perform manually.

Revision control: The plain-text script files could be stored in an industry standard version control system, providing a historic record of all changes made along with who made them and when. This also allowed multiple web developers to work without overwriting each other's changes.

Batching changes: Script Runner created a folder for each release containing the content class templates and related scripts specific to that release.

An indispensable tool for our big web project

When it came time to deploy the release to an environment, a developer would checkout the project and execute Script Runner, selecting which project and release to deploy. Script Runner would automatically update any content classes, elements and pages in mere minutes. Multiple releases could  be deployed at once, similar to rake migrations. If the production environment had release 1.1 and the developer deployed release 1.4, Script Runner would deploy releases 1.2 and 1.3 before deploying 1.4.

So not only did Script Runner reduce deployment times from from 5+ hours to mere minutes, it also ensured consistency between environments reducing regressions, and allowed the team to be more agile with frequent releases. Script Runner is a game-changing tool for working with OpenText Web Site Management Server and a key component to the success of the launch and ongoing development of the new Mackenzie Investments website.

Take your OpenText deployment time from hours to minutes

Script Runner was a huge time-saver for us, and it can do the same for your OpenText Web Site Management project. If you want to learn more about how Script Runner can help your team, be sure to get in touch.