feat: add Canary deployment activity to Deployment dimension

[venkatapgummadi]

Summary

Adds a top-level Canary deployment activity under Build and Deployment > Deployment, alongside the existing Blue/Green Deployment and Rolling update on deployment activities.

Motivation

DSOMM's Deployment sub-dimension currently defines two of the three industry-standard progressive-delivery strategies as standalone activities:

• Blue/Green Deployment (Level 5)
• Rolling update on deployment (Level 3)

Canary deployment — gradually shifting a small fraction of production traffic to a new artifact version while monitoring SLIs and security signals — is an established and widely adopted strategy used by regulated industries to reduce blast radius. Today the term appears in DSOMM only as a passing mention inside another activity's description text. There is no standalone activity, no UUID, no references, and no implementation reference for it.

This PR closes that gap.

Why Level 4

The new activity is placed at Level 4 to sit between Rolling (Level 3) and Blue/Green (Level 5):

Property	Rolling	Canary	Blue/Green
Rollback speed	Slow	Fast	Instant
Infra cost	1×	~1.1×	2×
Traffic risk	Medium	Low	None
Operational complexity	Medium	High	High

Canary requires more sophisticated traffic-control infrastructure than Rolling but does not require the duplicated-environment overhead of Blue/Green, which matches the Level 4 maturity bracket ("very high adoption of security practices") in DSOMM's progression definition.

Changes

• src/assets/YAML/default/BuildAndDeployment/Deployment.yaml: new Canary deployment activity (uuid, description, risk, measure, assessment, difficultyOfImplementation, usefulness, level, implementation, dependsOn, references for SAMM2 / ISO 27001:2017 / ISO 27001:2022).
• src/assets/YAML/default/implementations.yaml: new canary-deployment implementation reference with a public URL to Martin Fowler's canonical write-up.

Schema conformance

• All required fields per dsomm-schema-build-and-deployment.json are present: uuid, risk, measure, difficultyOfImplementation, usefulness, level, implementation, references, isImplemented, evidence, comments.
• References use the same SAMM2 / ISO 27001:2017 / ISO 27001:2022 taxonomy as the existing Blue/Green and Rolling entries.
• dependsOn references the Automated deployment process activity (uuid 67e1a9aa-9fbf-4ec5-a2de-400f01960c51), matching the Rolling-update entry.
• UUIDs were freshly generated as v4 and verified not to collide with any existing UUID in the repo.

Validation

• YAML syntax validated locally with yaml.safe_load after applying both edits.
• Activity structure mirrors the adjacent Blue/Green and Rolling entries to ensure rendering parity in the frontend repo.

Out of scope (intentional)

The existing typo blue-green-deploymen (missing trailing "t") in implementations.yaml is preserved as-is to keep this PR focused. Happy to open a separate PR for that if useful.

References

• Martin Fowler — Canary Release
• Google SRE — Canarying Releases

[wurstbrot]

thank you!

[venkatapgummadi]

Thank you for the fast review, @wurstbrot really appreciate it.

A bit of background since I'm new to the project: I'm a Technical Architect at Broadridge Financial Solutions (DCOE), where I lead the integration platform powering Wealth InFocus. Outside of that, I've published two open-source frameworks that overlap with DSOMM:

• ASCEND (https://github.com/venkatapgummadi/ascend) a four-layer DevSecOps framework with formal quality-gate definitions across SAST, SCA, secret detection, container scanning, IaC validation, DAST, and AI-augmented post-deployment synchronization, with reference configurations for GitHub Actions, GitLab, Jenkins, and Azure DevOps.
• AgentFlow (https://github.com/venkatapgummadi/agentflow) a multi-agent framework for dynamic API orchestration.

If you're open to it, I'd like to propose two further contributions:

1. Formal quality-gate definitions for the static and dynamic test depth dimensions severity-tiered thresholds, exception workflows, and audit-trail expectations, drawn from ASCEND.
2. A new activity covering AI-augmented post-deployment synchronization (AST-diff drift detection, ML-based conflict classification, LLM-resolution with property-based verification of security invariants) under the Deployment sub-dimension at Level 5.

Happy to scope either one as a separate small PR or draft a short proposal first whichever fits the project's review preferences. Either way, I'm planning sustained contribution to DSOMM going forward.

Sincerely,

Venkata Pavan Kumar Gummadi
IEEE Senior Member | MuleSoft Integration Architect
ORCID: https://orcid.org/0009-0005-4435-0197