Given the scale and complexity of enterprise applications, trying to improve release cycle time without compromising quality is a constant concern. In tightly-coupled architectures, release pipelines have multiple system dependencies which adds to the complexity of maintaining quality while managing the increased velocity of change. An effective release process requires close collaboration across all teams, from dev to ops — to not just deliver faster, but with a better-quality product.
In a recent webinar with Plutora, Gary Gruver talked about how to deal with the complexities of a tightly-coupled architecture. Gating code, getting test environments under version control, localizing the triage process, and giving test teams self-service access to test environments were among the range of topics he covered.
Gating code to localize the triage process
The heterogeneous nature of large enterprise releases often requires multiple release trains that combine both slower moving legacy systems of record, and faster Agile systems of engagement. This means as the build rate from dev increases, the probability that any given change will impact multiple systems also increases.
To reflect these dependencies, release teams establish a multi-stage testing strategy comes the foundation for the phases of a continuous delivery pipeline, where test environments reflect an increasingly complex configuration as builds progress toward production.
Source: Gary Gruver “Applying Agile and DevOps at Scale”
This strategy localizes the triage process and helps dev teams avoid debugging test failures that have nothing to do with the code. Establishing quality gates reduces multi-faceted triage scenarios, keeping defects as close to developers as possible and limiting progression into more complex test environments.
With Plutora, release managers define phases and quality gates to create a well-structured release process for promoting code along the deployment pipeline. Environment management teams assign test environments and related configurations to each phase of the release, so each environment is fit for purpose. Criteria for progressing builds is established and approval history is stored to meet compliance requirements.
Monitor product quality as code progresses along the pipeline
DevOps transformations implement automation to establish efficient and repeatable processes, but automation can limit visibility to the broader team.
Many activities and metrics in the CD pipeline — code commits, builds and their version numbers, test environment configurations, test plans created for user stories or defects, test cases run against each build, status and results of these tests — are not accessible to everyone on the release team because they take place within the specialized tools of dev and test teams.
Plutora aggregates data from dev and test tools so stakeholders can view test status and defect count in real time to evaluate risk at each phase of the CD pipeline. Reports are distributed automatically, reducing the need for time-consuming meetings.
The backdrop for monitoring application quality is getting test environment configurations under version control to ensure configuration accuracy. Plutora integrates with Jenkins to automatically fetch version-controlled development artifacts from the Jenkins build server, that way everyone can track the progression of code along the CD pipeline.
This view from Plutora shows version-controlled test environments of a CD pipeline.
Improve the partnership between dev and test
System thinking in Scaled Agile (SAFe) development highlights process wait states as a major inefficiency. The perpetual feedback loop of a CD pipeline results in a lot of hand offs from dev to test. These hand offs will compound delays if test environments aren’t available. It’s not uncommon for an organization to spend more time getting environments spun up and configured correctly than it does to write the code in the first place.
“A system can evolve no faster than its slowest integration point.” –Scaled Agile
Plutora helps expedite this hand-off in a couple ways. First, test teams are automatically alerted when new builds are ready for testing and where they will be deployed. Plutora also links Jenkins jobs to test environments, so QA teams can trigger a build on-demand (after approvals are granted and configuration changes tracked for compliance needs…this isn’t the wild west!) to efficiently move binaries along the pipeline.
And as dev team velocity increases, test teams may have a hard time tracking the change requests associated with a new build. Plutora automatically links change IDs with new builds, so test teams can quickly associate and assign appropriate test cases for accurate and complete test coverage. Centralized configuration management ensures tests are run on correctly configured test environments.
What is the test environment sequence in your major releases? What percent of defects are found in each one? How do you ensure accurate test coverage when new builds are coming from dev fast and furiously? Are your test teams waiting for accurately configured environments? The questions can be the starting points for relentless improvement to both embrace agility and establish built-in quality.
This view from Plutora shows the new Jenkins build version in the middle column, and the associated change ID’s in the righthand column that have been automatically pulled from the code commit in GitHub (leftmost column).
The post Create a Hiccup-Free Continuous Delivery Pipeline for Enterprise Releases — Tips from Gary Gruver appeared first on Plutora.
