Card Pipeline Deployment for Service Release Control

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Service and library teams often lack control over the product life-cycle, gradual release, rollback, monitoring, and deprecation of software, due to mixed ownership responsibilities, leading to compatibility risks and challenges in managing software updates.

Innovation Solution

Implementing an end-to-end deployment pipeline that allows for the independent deployment of 'cards' - units of source code - using a card deployment module, which enables gradual rollouts, auto-rollback, and monitoring, decoupling execution and routing layers, and utilizing triggers like internal pipelines, GUI/CLI for manual control.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Stability of the object's composition

If centralized deployment control is implemented, then deployment consistency is improved, but service and library teams lose ownership and control over their product life-cycle

Engineering Contradiction:
Improvedeployment consistencyVSAvoidteam ownership control
Core Design Contradiction:
Stability of the object's compositionVSEase of operation

Solution Approach 1:

The deployment system is segmented into multiple independent pipeline entities, each responsible for specific service or library teams. This allows centralized coordination while granting individual teams ownership control over their own deployment pipelines, resolving the contradiction between consistency and team autonomy.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A centralized deployment orchestrator acts as an intermediary between individual team pipelines and the overall deployment infrastructure. This mediator coordinates deployments across teams while allowing each team to maintain control over their own release processes, balancing centralized consistency with team-level ownership.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If gradual release and rollback control are enabled, then deployment reliability is improved, but deployment process complexity increases

Engineering Contradiction:
Improvedeployment reliabilityVSAvoiddeployment process complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary actions by creating canary deployments and monitoring configurations before full releases. This allows gradual release and automated rollback capabilities to be prepared in advance, improving reliability while keeping the actual deployment process simple through automation.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Automated monitoring and feedback mechanisms track deployment health metrics in real-time, enabling automatic rollback decisions without manual intervention. This feedback loop improves deployment reliability while reducing the perceived complexity by automating the control processes.

Inventive Principle:
Principle #23Feedback

3Productivity

If service and library teams are empowered with independent deployment control, then team productivity is improved, but compatibility risks increase

Engineering Contradiction:
Improveteam productivityVSAvoidcompatibility risk
Core Design Contradiction:
ProductivityVSObject-affected harmful factors

Solution Approach 1:

Each service and library team's deployment pipeline is configured with specific compatibility rules and monitoring parameters tailored to their particular software. This local customization allows teams to maintain high productivity while each pipeline enforces appropriate compatibility checks for its specific context.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

Manual compatibility verification processes are replaced with automated monitoring and testing systems that continuously check for compatibility issues. This substitution enables teams to deploy independently with high productivity while automated systems detect and prevent compatibility problems.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS10732962B1End-to-end deployment infrastructure
Publication Date: 2020.08.04 AMAZON TECH INC
  • US10732962B1 patent drawing
  • US10732962B1 patent drawing
  • US10732962B1 patent drawing

AI summary

Systems and methods as described herein may relate to the use of card pipelines in the deployment of a service and/or library change. Cards may, for example, include code and/or run-time systems that utilize the service/library component. A system such as a release controller may detect a change to a service/library component that is utilized by a plurality of cards, trigger a card pipeline to cause the execution of one or more tests, and if a test failure is attributable to the change to the service component, halt the deployment of the card pipeline, a second card pipeline (e.g., being deployed and/or tested in parallel). The order in which the card pipelines are exercised may be determined based on card quality scores generated based on quality metrics collected in association with operation of the cards over time.