Plutora Blog - Agile Release Management, Deployment Management, DevOps, Release Management
Running Blind with DevOps and How to Fix ItReading time 6 minutes
Background – What is your perspective?
Delivering software at an enterprise scale requires a team consisting of different roles and responsibilities. Each role has a different perspective which often requires different visibility into how work is progressing. Here are just four software delivery management roles and their unique perspective:
- Release Managers – Their perspective is to ensure the specific release is ready to be delivered with quality. “Are all the user stories complete and defects fixed?”
- Quality Managers – Their perspective is on testing. “We have this defect fix. Which release is it supporting, which application changed and which version of the application has the fix, and which environment has that version?”
- Environment Managers – Their perspective is offering test environments to the team and managing bookings and changes. “I need to provide test environments to the team. What are all my environments, who uses them, and what changes are scheduled?”
- Product Managers – Their perspective is knowing when their epic or feature is complete. “I have this epic to announce to the market. It spans multiple releases across multiple applications. When will it all be ready?”
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.
Plutora’s integration methods support any level of operational complexity and deliver toolchain visibility.Learn More
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.
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.
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.
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.
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.
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: