Running Blind with DevOps and How to Fix It

Although these are all different perspectives, the beauty is the data needed to support them is all the same. If the data is brought together into a robust data model with a flexible visualization layer, everyone can get their job done as well as be on the same page.

Problem - Running Blind

The problem is that this data is spread across multiple tools, multiple teams, using multiple processes. Trying to remove the blindfold and gain visibility is challenging and often requires manual processes that are slow and error-prone impacting time to market, risking quality, and reducing the overall output of the teams.

I worked with one customer that uses email to communicate each build and each deployment. Team members are flooded with email traffic and struggle to keep up with an accurate understanding of what is going on.

For example, here are the common categories of tools that are needed to support the different functional needs:

• Releases and their user stories - Stored in an agile planning tool like Jira, Rally, ADO, etc.

• Releases and their defects - Stored in a test tool like HP ALM, X-ray, etc.

• Applications and their commits and versions - Stored in a repo like GitHub, Bitbucket, GitLab, GitHub, etc.

• Environments and their application versions - Available via CI/CD tools like Jenkins, GitLab, Harness, etc.

Solution - Plutora for End-to-End Visibility

Plutora provides an integration layer to extract information from the existing set of DevOps tools. This data is brought into a common data model and then Plutora Release and Environment modules are used to manage and orchestrate for end-to-end visibility. This automation means it is fast and accurate. 

The Plutora platform is flexible and can integrate with any tool with an API and logic can be adapted for each customer as needed. Let’s look at some details using Jira, Xray, GitHub, and Jenkins.

Releases

The integration layer leverages webhooks such that when new Fix Versions for projects are created in Jira, Plutora can reach out and get the new release information and bring that into Plutora. A release template in Plutora defines the release process for that team including phases, gates, activities, and criteria. These templates can vary by team. 

Scope

The integration layer brings across all the scope from Jira, typically user stories, but can also include Epic and Feature information and assigns them to the release in Plutora. Very important here is that as things change in Jira, like status changes, new stories added, or existing stories removed, Plutora is kept synchronized.

Environments

Like with the release templates, the environments are captured in Plutora. All the applications along with all their microservices if applicable, as well as each instance of them, are arranged into environment groups, or end-to-end environments, for example, DEV, SIT, UAT, STAGE, PROD. 

Builds

The customer’s CI/CD pipelines are updated such that when any build occurs, that information is written to Plutora so there is a record of every build with the associated commit, user story, date, time, duration, and more. The Plutora integration layer then correlates that specific build to the associated release. This is a key piece. Now we are linking the user stories that came from Jira to the build that came from Jenkins / GitHub.

Deployments

Similarly, the CI/CD pipelines are updated such that when any deployment occurs, that information is written to Plutora. A record for each deployment is captured as a Test Environment Change Request. This can be fully automated, like for a DEV environment. This can also be orchestrated by Plutora, typically for the shared environments, so some approval workflow can be used to launch the deployment at the right time. As the deployments occur, the version of the application or microservice on that environment is automatically updated in Plutora. This also provides a calendar of all the upcoming environment changes.

Benefit - More, Better, Faster

What is the result? A real-time, accurate view of every release, story, build, and environment that enables supporting the different perspectives.

• Release Managers - They can see the release, the user story status as well as any supporting commits.

• Quality Managers - They can see the release, user stories, supporting builds, and the version on every environment.

• Environment Managers - They have a view of all the integrated environments, their components, and their versions as well as a calendar of upcoming changes.

• Product Managers - They can see their Epics and Features and how they are being supported by the releases and user stories. 

The benefit is a significant boost in productivity allowing more to be delivered, faster and better. One Plutora customer increased their features delivered by 97% while reducing production incidents by 30%. 

To learn more about how to address get this end-to-end visibility:

• Watch 9-minute demo video on unlocking advanced data analysis

• Request a live demo

• Get a free trial