Welcome back! For those of you just joining us, this is part two of a pair of blog posts discussing CI/CD with rule apps – you can find the previous post here.
Part Two: irCatalog Check-In Triggered, Catalog-Sourced Rule App, Promoting Pipeline
Scenario:
For this sample, we’re going to use a rule app that is stored in an instance of the InRule repository tool (irCatalog). We have an accompanying GitHub repository containing all our test scenarios, and we want to run the new version of a rule application against all those tests whenever one is checked into the catalog. If all tests pass, we then want to promote the rule app from one instance of irCatalog to the next one down the line.
Ready? Let’s take a meander through it. You can follow along with the GitHub Repo that accompanies these posts.
Trigger from irCatalog Check-In
Remember that irCatalogExtension Helper folder we skipped over in part one of this series? This is where that project comes into play. While the irCatalog service does not have a formal integration hook, we are able to leverage the WCF Endpoint Behavior configuration to add a Behavior Extension that injects a Parameter Inspector into the request/response pipeline. This gives us visibility into requests as they’re entering the catalog, and responses as they are returned. We can inspect those as they pass and, if desired, manually trigger our pipeline from there.
In the CheckinRequestListener project, the RuleApplicationParameterInspector is where the application logic lives; that structure can be used as a foundation for creating custom assemblies. The essence of the logic is that when a check-in or an apply label request completes, it may call out to Azure DevOps to trigger the pipeline to execute.
In order to trigger the pipeline, the request needs to contain an authentication token from Azure; the process to retrieve that is outlined here. There are several other pieces of information required, including the Pipeline Organization, Project, and Pipeline ID (hint: the Pipeline ID can be found in the URL of the Azure DevOps Portal when the pipeline is open).
In the Catalog Extension project, the DevOps pipeline queue request is abstracted into the AxureDevOpsApiHelper class. More information about what else that API supports is available here. The readme in the project repo contains instructions about how to modify the web.config to enable the custom extension to WCF behavior, and also for the extension to have the configuration information it needs to initiate the DevOps pipeline.
Pipeline Structure
Like the pipeline discussed in the previous post in this series, this pipeline is structured with a template to make it reusable. We’re also passing parameters into the template indicating which rule app we’re working with, as well as which source and destination catalogs we want to use. Since we’re manually triggering it with the irCatalog extension, we do not have any automatic triggers configured on this one.
Catalog Credentials
As before, because we want to avoid storing credentials somewhere unsafe, we’re keeping them in Library Variable Groups. Since we’re going to be pulling in two Variable Groups at the same time in the pipeline (one for source and one for destination catalogs), we need to create “Source” and “Dest” prefixed variables and groups to avoid name collisions when importing multiple groups into the same job.
Test
Our job to perform the tests here is nearly identical to the previous post, but rather than providing a file path for the rule app to test, we’re providing the catalog credentials that we retrieved from the credential store. One unfortunate note here is that (as of July 2019) Azure DevOps has an open issue that Variable Groups cannot be imported using a name containing a variable substitution. Until that is addressed, the template only works with a fixed pair of catalog credential library variable group names.
Promote
Once we’ve tested and validated that all is well, we’re now ready to promote between catalogs. This is performed in fundamentally the same way as the previous post’s irDistribution request, but with a different command line tool and many more parameters to specify connection information for the two catalogs.
You Did It (Again)!
As before, you can view the full pipeline and GitHub structure of the catalogSourced-TestAndPromote-pipeline at https://github.com/InRule/DemoRuleCICDPipeline. This is just one example of the different ways these pieces can be put together. Feel free to adapt the elements of this exercise to whatever your needs are and build out a CI/CD pipeline that give you exactly the functionality you need in your organization.
Was this helpful for you? What would you do differently? Let us know in the comments below!
