Cross-team collaboration is a practice that nearly all companies have but few achieve. It’s achieved when disparate teams work together to share knowledge, tools, and goals. At its best, cross-team collaboration is a natural byproduct of your team’s typical workflow. At its worst, it’s an obstacle to getting the job done and can lead to resentment between colleagues.
Your software delivery pipelines are a logical place for your technology team to collaborate. With the right tools, they can share their output in a manner that will enhance their process rather than intrude on it. CloudBees Continuous Integration (CloudBees CI), which is built on Jenkins, has those tools.
(Side note: Interested in learning more about how to scale best practices in Jenkins team management across the enterprise? CloudBees CI can help.)
In this tutorial, you’ll learn how to use CloudBees CI Cross Team Collaboration to improve collaboration. You’ll set up jobs on two controllers. On one controller, there will be a job that publishes an event. On the other controller, there will be a job that is listening for the event that was published from the first controller. First, you’ll set up a simple event; then you’ll use one to deliver information about the publisher.
CloudBees CI Cross Team Collaboration
Effectively sharing information between teams isn’t easy. Each team has its own problems, schedule, and priorities. Even when it’s a critical part of delivering software, coordination between groups is frequently an afterthought.
But we’re software and DevOps engineers. We know how to use automation to solve problems, right? Let’s look at a few of the typical cross-team collaboration solutions.
Probably the most basic mechanism for collaboration is a shared repository. You can use a Git repository to share code or configuration information. Depending on the nature of the data, you can share your data with other teams via read-only access. But this means that the other groups have to poll the repository for changes. There’s no notification system, and the data can only flow one way.
Another option is to share a read/write repository and collaborate via pull requests. This is closer to true collaboration, of course. But it means that the teams have to work closely together and are directly involved in each other’s schedules and workflows.
Jenkins has fundamental collaboration features already built-in. You can trigger a job based on a change in a repo, which is how you would coordinate pipelines on shared repositories. You can also use the successful completion of one job to trigger the start of another. While this will keep the ball rolling when one team completes a task that affects another, the completion of one job only conveys that it finished; it’s an incomplete message. It also requires that the triggering job be aware of the client job(s) that need triggering.
That’s where CloudBees CI Cross Team Collaboration comes in. It’s a publish/subscribe system that gives you a way to send and receive messages from your jobs. These messages are delivered to any other interested job in your system.
The messages are “fire and forget.” The publisher doesn’t wait for a response and doesn’t know which or how many jobs were listening for the message. A publisher can even send more than one message, depending on the job.
Three Required Plugins
Cross Team Collaboration requires the installation of three plugins on your controllers for full operation.
The notification-api plugin sends messages between jobs and teams
The pipeline-event-step plugin adds a pipeline step to Pipeline DSL.
Operation-center-notification gives the ability to route messages between different controllers by leveraging the CloudBees CI Operations Center. You only need to install it if you want to route messages between different controllers. We’ll be using it for this tutorial.
Cross-Team Collaboration Example
Suppose a team has a set of Java libraries that are configured for continuous integration. Some of the build jobs are very fast. Others, unfortunately, are not. They rely on slow C++ builds that are required for JNI libraries. These slow builds take time and slow down testing and the time required for QA and development teams to receive new builds. The teams want to add a security scan for each build, but these scans would add even more time to each build, so that process needs to run inside a separate job.
With CloudBees CI Cross Team Collaboration, they can add a publish step to each build. That step can publish a simple message telling a security scan job which library was built to pull it down from their artifact repository and perform a new scan.
Let’s see how they would do that.
Set Up Cross Team Collaboration
First, we’ll start with an Operations Center and two controllers.
Before you can send Cross Team Collaboration events, you need to install the required plugins on each controller. To send events between different controllers, each one needs the three plugins outlined above. Let’s install them.
Install Plugins
Starting on one controller, click the Manage Jenkins menu item on the left.
Next, click on Manage Plugins.
Now, click on the Available tab and search for “notification-.”
This will bring up the Notification API and Operations Center Notification plugins. Check them.
Finally, search for “pipeline step.” This will bring up the third plugin, “Pipeline Event Step.” Check it, too.
Click on the “Download now and install after restart” button on the bottom of the page.
The controller will download the plugins and start the installation.
When the next page loads, click the “Restart Jenkins …” checkbox and wait for the controller to restart.
Repeat these steps on your second controller.
Configure Notification
Once you have installed the plugins, click on “Manage Jenkins” again, and you’ll see a new configuration option on the right.
Click this, and you will go to the configuration page.
Enable notifications and select the “Operations Center Messaging” router implementation. This will route all messages through your Operations Center so that all controllers will see them.
Make sure you configure both controllers this way, and you’re ready to send a message!
Basic Cross-Team Collaboration
CloudBees CI Cross Team Collaboration supports both simple and JSON messages. You’ll start with a simple message.
Go to your first controller and add a new item.
Call it simplePub and select Pipeline as the item type.
To keep the tutorial simple, you’ll enter pipeline code directly in the job configuration instead of using a source repository.
Here is the code:
pipeline {
agent any
stages {
stage('Example') {
steps {
publishEvent simpleEvent('NewLibrary')
}
}
}
}
Enter it in the Pipeline script box in the job configuration.
This code sends a single simple event with a payload string of “NewLibrary.”
Save your configuration and run the job by clicking “Build Now.”
After the job completes, examine the console output.
The job completed successfully. It published the event even though no other jobs were listening for it.
Now, on your second controller, create a simpleSub Pipeline job.
Enter this code:
pipeline {
agent any
triggers {
eventTrigger simpleMatch("NewLibrary")
}
stages {
stage('Example') {
steps {
echo 'received NewLibrary'
}
}
}
}
This job subscribes to a simple event with the same payload as our publish job. When it receives the event, it prints a message indicating receipt.
For this event to fire, you have to run it once. Click “Build Now,” and it will run once. Now it’s ready to receive events.
Go back to your first controller and run simplePub. Switch back to the second controller, and you’ll see the simpleSub ran again!
You’ve created a basic Cross Team Collaboration publisher and receiver!
Complex Cross-Team Collaboration
Simple events will take you a long way toward better cross-team collaboration. But you may want to trigger jobs based on more complex criteria or send more than one piece of information in an event. For that, you have JSON events.
Let’s set up an example.
Create a new Pipeline job called jsonPub on one controller.
Here’s the code:
pipeline {
agent any
stages {
stage('Example') {
steps {
publishEvent jsonEvent('{"libraryName":"NewLibrary", "version":"1.099"}')
}
}
}
}
This job publishes a JSON event with two fields: a library name, and a version.
Now, on the other controller, create a Pipeline job named jsonSub.
Here’s the code for the event subscriber:
pipeline {
agent any
triggers {
eventTrigger jmespathQuery("libraryName=='NewLibrary'")
}
stages {
stage('Read Event Data') {
steps {
script {
def eventCause = currentBuild.getBuildCauses("com.cloudbees.jenkins.plugins.pipeline.events.EventTriggerCause")
def version = eventCause[0].event.version
echo "version=${version}"
}
}
}
}
}
This job subscribes to events for a library named NewLibrary.
It accesses the event information by extracting the build cause. Then it parses out the version field. Finally, it prints the version.
Run this job once to set up the subscription. It will fail since the build cause is not an event. In production code, you would add a check to validate that the job was actually triggered by an event.
Now, run jsonPub on the other controller. Check jsonSub. It ran and printed out the version.
You set up a JSON event, and then you parsed it in a subscriber!
Wrapping Up
In this tutorial, you learned how CloudBees CI Cross Team Collaboration provides a way to send events between CloudBees CI controllers. You set up two different kinds of events and used them to trigger jobs.
Based on how these events worked, you can see how Cross Team Collaboration makes it possible to trigger a new job and supply it with information it can use to react appropriately. For more information, check out the documentation, and see how you can use Cross Team Collaboration to build more robust pipelines.
This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!).