Merge pull request #76 from venkatapgummadi/feat/canary-deployment-activity

feat: add Canary deployment activity to Deployment dimension

Author: wurstbrot

src/assets/YAML/default/BuildAndDeployment/Deployment.yaml

@@ -38,6 +38,70 @@ Build and Deployment:
       isImplemented: false
       evidence: ""
       comments: ""
+    Canary deployment:
+      uuid: c4204a32-2545-4424-b524-d1cc52b46abd
+      description: |-
+        A *canary deployment* gradually shifts a small fraction of production
+        traffic to a new artifact version while monitoring service-level
+        indicators and security signals. If error rates, latency, or security
+        scanners (such as DAST probes against the canary fleet) report
+        anomalies, traffic is rolled back automatically before the new
+        version reaches the broader production population.
+
+        Compared to *Blue/Green Deployment*, canary requires only a small
+        delta in infrastructure cost (commonly 5-10% additional capacity
+        rather than a doubled environment) but demands more sophisticated
+        traffic-control infrastructure such as a service mesh, an
+        application load balancer with weighted routing, or a feature-flag
+        platform.
+      risk: |-
+        A new artifact version can introduce regressions or security
+        issues. Promoting it to 100% of production traffic in one step
+        exposes the entire user population to those issues before they
+        can be detected.
+      measure: |-
+        Adopt a canary deployment strategy in which a small percentage of
+        production traffic (commonly 1-10%) is routed to the new artifact
+        version for a defined observation window. Promotion to higher
+        traffic percentages is gated on automated SLI checks (error rate,
+        latency, saturation) and security checks (DAST, runtime anomaly
+        detection). Rollback must be automated and triggered by gate
+        failure without human intervention.
+      assessment: |
+        - Canary stage exists in the deployment pipeline with a configured
+          initial traffic percentage and observation window.
+        - Automated promotion and rollback gates are defined based on SLIs
+          and security signals.
+        - Audit logs of canary deployments and their promotion or rollback
+          decisions are retained.
+      difficultyOfImplementation:
+        knowledge: 3
+        time: 2
+        resources: 2
+      usefulness: 3
+      level: 4
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/canary-deployment
+      dependsOn:
+        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
+      references:
+        samm2:
+          - I-SD-A-3
+        iso27001-2017:
+          - 12.1.2 # Change management
+          - 12.5.1 # Installation of software on operational systems
+          - 14.2.2 # System change control procedures
+          - 14.2.9 # System acceptance testing
+          - 17.2.1 # Availability of information processing facilities
+        iso27001-2022:
+          - 8.14
+          - 8.19
+          - 8.29
+          - 8.31
+          - 8.32
+      isImplemented: false
+      evidence: ""
+      comments: ""
     Defined decommissioning process:
       uuid: da4ff665-dcb9-4e93-9d20-48cdedc50fc2
       description: |-

src/assets/YAML/default/implementations.yaml

@@ -75,6 +75,11 @@ implementations:
     name: Blue/Green Deployments
     tags: []
     url: https://martinfowler.com/bliki/BlueGreenDeployment.html
+  canary-deployment:
+    uuid: cd49f792-a158-4b93-ac55-fd773954b217
+    name: Canary release
+    tags: []
+    url: https://martinfowler.com/bliki/CanaryRelease.html
   docker:
     uuid: cc47b2e3-6ee5-4926-af3a-d418ef91c8ba
     name: Docker