Drive your releases with delivery patterns

The 2019 Accelerate State of DevOps Report shows that organizations across all types of industries are adopting DevOps best practices such as Continuous Integration and Continuous Delivery to increase deployment frequency and reduce the lead time required to implement software changes. However, while some organizations have successfully sped up the time-to-market for changes, most are still trying to strike the right balance between speed and quality while dealing with dependencies across teams and application components.

The problem: Enterprise-scale software delivery is harder than you think

In theory, the Continuous Integration and Continuous Delivery (CI/CD) process for getting a single software artifact into production is simple: you write the code, you merge it into a source control management system, your CI tool builds the artifact, your test tools automatically test it, and your deployment tool pushes it to your production environment. In reality, the process is much more complicated, because:

• Development teams start out with a list of features and fixes that are intended for a specific release, but the work isn’t always finished by the planned release date, and other stakeholders often insert emergency work into the process
• The CI/CD process goes through loops and backtracks as builds, tests, and deployments fail, much of which is invisible to business stakeholders
• Enterprises develop and deploy numerous applications, which means that at any given time, many teams are working on many different applications, using different tools and technologies, with different requirements and different dependencies
• Most release status tracking is limited to technical dependencies between release pipelines, but many stakeholders want to monitor the progress of software delivery from a business perspective
• The work required to collect, collate, and communicate release status data from various tools and teams is tedious manual work that’s highly prone to human error

The reality is, managing complex application release processes across the enterprise is hard. Teams move at different speeds through iterative build-test-deploy cycles; dependencies between applications slow down pipelines and introduce risk; planned features are delayed or descoped without business stakeholders knowing about it; and the information required to track release activities is spread across a hundred different tools and systems.

The solution: Patterns that track software delivery from a business perspective

To help organizations achieve effective enterprise-scale software delivery, the XebiaLabs DevOps Platform 9.5 introduces delivery patterns, the world’s first mechanism for tracking, synchronizing, visualizing, and controlling the activities that must be done to release applications to end users, all from a business delivery perspective. Delivery patterns go beyond simple point-to-point dependencies between technical pipelines; instead, they allow teams to track logical dependencies between application and components. With delivery patterns, it’s easy for everyone who’s involved in the software delivery process to track the lifecycle of the things they care about—bug fixes, user stories, new features, change requests—from planning to production, even when things go wrong.

Delivery patterns allow you to:

• Control business deliveries while giving teams freedom: Let DevOps teams design and execute their own release processes, while controlling the high-level delivery of business applications to your end users
• Achieve stable multi-pipeline business application deliveries: Reusable, repeatable patterns for development, testing, and deployment make the delivery of business applications consistent and predictable
• Model your organization’s release strategy: You can apply industry-standard delivery patterns such as Scaled Agile Framework release trains, or model your own release strategy in reusable patterns
• Synchronize deliveries across release pipelines: Let teams complete release activities at their own pace while preserving dependencies between releases, so nothing is pushed to production without its requirements being satisfied
• Track important items through the delivery process: Business stakeholders have visibility on new features, change requests, and other items, from planning to production—no matter what technical processes are happening to build, test, and deliver those items
• Get a high-level, cross-release overview of tracked item status: Technical and business stakeholders can get a 50,000-footview of what’s happening with a feature
• Descope items with full transparency for everyone: When a feature, bug fix, or other item has to be removed from a release, the removal is visible and tracked in the context of a delivery, so no one is left in the dark

What you get with delivery patterns

Uber view of software deliveries

Delivery patterns allow all stakeholders to see the deliveries that are planned, in progress, and completed. You can also drill down to visualize the components that are delivered as part of a milestone.

Patterns

Patterns define rules that teams must comply with as they work with their own release pipelines, processes, and tools, across different applications or application components. You create a pattern to represent a complete business application, or to represent multiple applications that are based on multiple components across different release pipelines. The pattern documents the flow of activities that the application(s) or component(s) must move through as they go from planning to production. Patterns are reusable, which means they help teams make their business software deliveries repeatable and consistent.

XL Release supports patterns such as:

• Scaled Agile Framework (SAFe) release trains
• Multi-pipeline releases
• “Big bang” milestone releases
• Master/subreleases
• Interdependent microservice releases

Deliveries

After you define a pattern, the deliveries that you instantiate from it follow the same sequence of steps.

Transitions

You can optionally place a transition between stages to act as gatekeeper for the following stage. Transitions are helpful in scenarios where all the components must be ready before moving to the next stage. The components wait in a stage until all dependencies are resolved. A business stakeholder can choose to transition items to the next stage by waiting for the dependencies to be resolved or by taking a business decision to descope items that are not ready by the defined timeline.

Tasks

Releases use special tasks to send information about tracked items to deliveries. These tasks synchronize releases with deliveries and provide bi-directional, event-based component synchronization for multi-pipeline releases:

• Bi-directional: Releases send information about tracked items to the delivery, and the delivery can trigger releases to wait or fail based on certain criteria
• Event-based: You control when and how releases update the delivery by adding Delivery tasks to the release
• Component synchronization: You can hold tracked items at points in the delivery so that they all proceed to certain activities (such as testing or deployment) at the same time
• Multi-pipeline releases: Business application delivery often requires many technical release pipelines to run

To see how delivery patterns can help you achieve effective enterprise-scale software delivery, sign up for a free trial of the XebiaLabs DevOps Platform today!

Learn More

• Get into the Same Rhythm: Software Delivery Synchronization
• Take Control of Release and Audit Complexity with the XebiaLabs DevOps Platform 9.5
• Gartner 2019 Magic Quadrant: Application Release Orchestration