The Power of Selective Syncing Combined with Software Lifecycle Analytics

A common challenge we come across is that while you may want to send all data from your DevOps or Event-based tools to a database for analysis, you don’t want to have all of those same events synchronized across your software lifecycle tools.

Selectively syncing the events within your DevOps tools allows you to have the best of both worlds. The diagram below illustrates an example of how this can work, which is explained in more detail below.

Selectively Syncing Events

In the example above you will likely want all of the events from Jenkins and SonarQube going into your database so that you can report on both passed and failed builds. Or you can report on any of the numerous scan measurements and violations in SonarQube.

However you don’t want all the events from these tools coming into JIRA or HP ALM as defects because it is overwhelming and completely unnecessary.

Take for example the integration between Jenkins and HP ALM. You would never create a defect in HP ALM for every build that happens in Jenkins. Passed builds are a good thing, not a defect. 

A more practical approach is to only sync the failed builds, or maybe failed builds from certain build jobs. Understanding when you want data to flow, and what data you want to flow creates a much more practical and effective integration between your tools.

In the SonarQube example, a single scan could report thousands of violations in your code, but many of them are minor and you don’t need to worry about fixing them. It would be nice if they were fixed, but what developer wants to see thousand of defects in JIRA saying you need to fix this low severity violation every time SonarQube runs.

Syncing only the high severity violations that SonarQube uncovers is much more practical.   Or, you might decide that individual low severity violations aren’t a concern, but the large collection of low severity tickets is a problem. 

In that case, a single JIRA issue can be created that links to all low severity violations.

Selectively Syncing Changesets

The example integration between GitHub and Rally is similar, but a little different in that changesets or commits in your source code management tools need traced to the reason for the change.   

After all, if you aren’t working on a user story, defect or other work item, then why are you changing the code?? 

To understand the traceability, you need to get some of the details of that changeset into the work item, but we’re not creating a new work item like we are in JIRA or HP ALM. We’re actually getting the details of the changeset into a work item so that you can see all of the commits or changesets associated with a single user story, for example.

Users are then able to click a link and navigate to the full details of changesets or commits.

Tasktop uses Gateway internally to update JIRA issues with corresponding code reviews

Software Lifecycle Data Analysis

Whereas you may only want to sync certain pieces of data between your tools, being able to send all data you collect from your DevOps tools to a database allows for deep visibility into your software delivery and development process.

The build results, test results and other events collected here in real time can be joined with the wide-ranging data in your data warehouse and pulled into new and existing reports.

To achieve the software lifecycle architecture above we used the Gateway capability of Tasktop Sync and Tasktop Data.