Introduction
One question that is regularly brought up during customer training sessions is how to integrate Rule Applications into a company’s existing Continuous Integration and Continuous Delivery or Deployment (CI/CD) pipeline. CI/CD has become standard practice in many organizations because of the opportunities for automation and risk mitigation it provides, and it can be a great idea to include Rule applications in that organizational standard.
- Continuous Integration involves automatically running an application through a series of tests following each code change to ensure that what was checked in did not break any existing functionality. This is a great way to mitigate the risks around applications that are frequently updated.
- Continuous Delivery (or Deployment) takes the updated code which was verified in the CI portion of the process and delivers it to the next stage (generally the next environment along the line to production).
InRule offers a variety of ways to manually perform those tasks (such as irVerify’s test scenarios and irCatalog’s rule promotion), but many customers find that they want to automate portions of the process using functionalities exposed through InRule’s irSDK.
This two-post series will walk through the process of automating CI/CD of rule apps using Azure DevOps from a few architectural and functional standpoints, and the accompanying GitHub repo contains samples that you can use as a reference while building out that automation for your own organization. While these samples use Azure’s DevOps pipelines, the same concepts will translate to just about any pipeline you may want to use. If you are using Azure DevOps, I found this to be an excellent resource.
Part 1: GitHub Push Triggered, File-Sourced Rule App, InRule for JavaScript Compiling Pipeline
Scenario:
For the first sample, we’re going to use two simple file-based rule applications (“rule apps”) that target InRule for JavaScript, each checked into their own folders within a GitHub repository. Each rule app has test suites checked into the application folder, and the repository also contains several helper executable applications. Whenever a rule app is checked in, we want to run any tests in the folder against those rule apps to make sure everything is functioning as expected. If all’s well, we will then want to submit the rule app to the irDistribution service to compile it into a JavaScript file, and include that file as a build artifact.
Let’s walk through some key aspects of this pipeline:
Trigger from GitHub Check-in
We want our pipeline to run every time someone checks in a Rule App or test scenario, so we’ll direct our pipeline to automatically execute whenever a file is changed in a location where those files will be stored.
Pipeline Templates
While we could hard-code everything in the pipeline, it’s always good practice to make components reusable. To accomplish this, the pipeline is built using templates, with a parameter passed in that allows it to execute on the desired rule app. This requires that a consistent naming structure be used throughout the rule apps in the repository, but it means that adding a new rule app to the pipeline is a trivial exercise. Note that this structure does mean that all jobs will be run when a trigger occurs.
Helper Applications
Throughout these pipelines, we’re using several different helper console applications that bootstrap irSDK functionality. To make those available to the pipeline, they are included in the GitHub repo in a “Helpers” directory. The three pre-built helpers are compiled from the Samples repository. We’ll discuss the IrCatalogExtension in part two of this series.
Licensing irSDK Helper Applications
Those helper applications require an InRule license in order to execute, and since we are not able to run the InRule Activation Utility on the pipeline host, we’ll need to include a license.xml file to allow the helper applications to successfully execute. Since we do not want to store our license in the repository itself, we can instead save it in our Pipeline’s Library as a Secure File, copying that into our build Agent’s TempDirectory as part of the pipeline. Then, we can copy the testing helper application into the same TempDirectory to be able to execute without issue.
Run All Test Suites
Once we have all those pieces in place, we’re ready to run tests! Again, in keeping with the foundation of reusability, we’re going to run a script that iterates through each test suite file in the directory. This script will automatically run all tests without any hard-coded names. As a side note on this, the Test Suite Manager in irSDK has some dependencies on full .NET Framework that prevent it from being compiled as a .NET Core application.
Conditional Next Step
The next task we want to do is compile the rule app using the irDistribution Service, but ONLY if all the tests executed successfully. To do that, we can make the packaging job dependent on the successful execution of the testing job.
Using Secure Credentials in Execution
Calling the irDistribution Service requires an authentication token to be passed in, which (like the license file) should not be stored in the GitHub repository. Because this is a simple text string, this token can be stored in the library as a secret variable in a variable group and imported into the job.
Creating the Artifact
Once we’ve copied over the Build InRule for JavaScript helper application to the same directory we previously placed the license file, we’re then able to execute the wrapper for the irDistribution Service and save the compiled InRule for JavaScript file. That can then be published as a Pipeline Artifact to be used down the line as needed.
We Did It!
The full pipeline and GitHub structure of the fileSourced-IrJS-TestAndBuild-pipeline is available at https://github.com/InRule/DemoRuleCICDPipeline. This is just one example of how these pieces can be put together, but you can certainly adapt the elements to whatever your needs are and build out a CI/CD pipeline that give you exactly the functionality you need in your organization.
Now check out part two of this series, where we cover a pipeline with integrations into irCatalog!
