Continualoop Blog

So you've got your delivery pipeline all set and delivering releases. Developers are delivering code into source control, lets say Git as an example, and from there you're doing automated builds in Jenkins, and using IBM's UrbanCode Deploy to automate deployments. Everyone is happy because releases are getting out the door quicker than before and with less effort! And the automated tests you've added to the pipeline are helping weed out issues earlier, so quality is improving as well. Figure 1 - A common representation of a software delivery pipeline. Image downloaded from http://www.logigear.com/magazine/continuous-delivery-and-devOps/mega-trends-in-testing-continuous-delivery-production-line-and-the-deployment-pipeline/ in November 2017. But one thing that isn't as easy to do is get a sense for what is happening in your pipeline. Both from the point of view of seeing where a particular set of changes are in the pipeline, as well as getting a sense for

I'm going to assume you're already managing your plans and work items in Rational Team Concert (if not, read more here: https://jazz.net/products/rational-team-concert/ ). Have you wanted to track the flow of work through a set of steps in a defined multi-stream process using RTC? I've recently implemented an extension to RTC for a customer that does just this and I thought I'd write about that here. I'm not able to share the code for this (sorry), but hopefully these notes will be useful for anyone looking to implement their own solution. Figure 1. - Simple example of a "defined multi-stream process" In figure 1 we see a simple example "defined process" which exhibits the following characteristics: With the exception of the first step, all other steps are dependent on their "upstream" steps completing before they can start. Each step is owned by a team i.e. team members of that team are able to claim the step to work on