Tracking value stream data from dot to deployment

From an issue’s active sprint and most recent review comment, to a build’s passing tests and component versions, there is an endless amount of data to track and analyze with HCL Accelerate. While every piece informs a deeper picture of our DevOps journey, sometimes it can be a challenge to know which pieces and relations need to be in place for a specific task. In this post, we are going to zero in on what pieces matter most to a typical end-to-end value stream flow so we can see a work item move from your first stage to your last. When we are finished, we will have a conceptual understanding of what it takes to see an Issue in your tracking tool link all the way to a particle built, deployed, and tracked in an environment’s stage for a typical value stream.

First, let’s discuss what a typical value stream might often include. If you’re completely new to Value Streams and have questions like, “how do I initialize a Value Stream in the first place,” check out our HCL Accelerate tutorial videos or request a one-on-one demo. Once you have the basics setup, come back to learn more about what properties of the integration drive the movement of work items through your value stream.

A typical value stream might contain the following stages: Backlog, Selected For Development, In Progress, In Review, Merged, Built, Dev, QA, and Prod. From one Value Stream to another there is likely plenty of variance, but the basic idea of Planning stages (Backlog and Selected For Development), Development Stages (In Progress, In Review, Merged, and Built), and Deployment stages (Dev, QA, and Prod) are represented here in a way that will allow us to illustrate the properties end-to-end that link Builds and Deployments back to Planned Items in order for Accelerate to more visibly quantify your DevOps process.

At the most basic level in HCL Accelerate, we have the Dots, Builds, and Deployments. Dots get worked on in various commits and merged in Pull Requests. At some point, those commits will be built and given a version. When that versioned build gets put into an Environment, we have a Deployment. Now lets dive into these relations and the properties that inform them.

1. Dots – The dot is the starting point in your value stream, and it will be all we typically see in the Backlog and Selected For Development stage. It will link to Commits and Pull requests (both from your source control tool) by commit and pr associative link rules.
   1. Pull Requests – The pull request (PR) is the piece that usually will inform the in Review stage. It won’t further associate the dot towards the deployment, but it is likely to be relevant to a couple stages in your value stream. It contains a property that references the relevant commit for the code in the pull request
   2. Commits – The commit data objects store a reference to their dot’s id, as well as to any relevant pr id.
2. Builds – A build is stored with references by id to all of the relevant dots, commits, and PRs contained that are new to the code for that build.
   1. Versions – Versions contain references to all of these previously mentioned objects, but do not hold a reference to deployment.
3. Deployments – The Deployment has the version name to tie in to the build. It also importantly has an application Id and an environment id, that respond to an application on the value stream’s pipeline, and an environmental stage of the pipeline that the application will be deployed in (at the related version)

Now that we’ve taken a deeper dive into what makes an HCL Accelerate Value Stream flow, I hope you’re ready to get even more out of your DevOps practice with Accelerate. The more we know about our processes, the more efficient we can make them. So knowing more about the processes we use to tell you more about your processes might even make your efficiency more efficient.

You can get started with HCL Accelerate today with our free Community Edition. Get it here.