deployment-manager

on:
  push:
    branches: [main]
...
kubectl set image deployment/app-green app=app:${{ github.sha }}
...
kubectl patch service app-service -p

The example CI workflow deploys and switches Kubernetes service traffic automatically on a push to main, with no explicit manual approval, namespace/cluster allowlist, dry-run, or rollback decision gate shown.

- uses: actions/checkout@v3

The GitHub Actions example pins a third-party action only to a major version tag rather than an immutable commit, which is common but leaves update/provenance risk if copied into a real pipeline.

run: |
  docker build -t app:${{ github.sha }} .
  docker run --rm app:${{ github.sha }} npm test

The skill provides shell/CI examples that build and run containers. This is expected for deployment guidance, but it is executable automation that users should review before adopting.

- name: Switch Traffic
  run: |
    kubectl patch service app-service -p

- name: Cleanup Blue Environment
  run: |
    kubectl set image deployment/app-blue app=app:${{ github.sha }}

The example switches service traffic and then updates the blue environment, which can propagate a bad release broadly and reduce immediate rollback separation if not gated and contained.

kubectl rollout undo deployment/$service_name

Rollback operations require Kubernetes privileges over deployments; this is aligned with deployment management, but users should notice that the skill's examples assume sensitive operational authority.

send_slack_notification "✅ Rollback completed for $service_name"
send_alert "🚨 Rollback failed for $service_name"

The rollback example implies external notification integrations. This is normal for deployments, but recipient, workspace, authentication, and data-sharing boundaries are not specified.