User suggests implementing an automated validation mechanism for release governance in Kubernetes that checks cluster health signals before CI/CD deployments.
Hi everyone 👋 I’ve been exploring how teams enforce **release governance in Kubernetes environments** before allowing CI/CD deployments. Many pipelines rely only on **tests passing**, but they don’t validate the **actual cluster state** before a release. For example, a deployment might technically succeed even if the cluster is already showing warning signals like unstable pods or node issues. To explore this idea, I experimented with a **prototype pipeline** that validates release readiness across multiple layers. The pipeline includes: • Automated testing with Allure reports • DevSecOps security scanning (Semgrep, Trivy, Gitleaks) • SBOM generation + vulnerability scanning (Syft + Grype) • Kubernetes platform readiness validation • A final **GO / HOLD / NO-GO release decision engine** For Kubernetes validation it checks signals like: • Node readiness • Pod crashloops • Restart risk patterns • General cluster health signals All signals are consolidated into a **single release governance dashboard** that aggregates results from testing, security, SBOM scanning, and cluster validation. GitHub repo: [https://github.com/Debasish-87/ReleaseGuard](https://github.com/Debasish-87/ReleaseGuard) *(I'm the maintainer of this project.)* Demo video: [https://youtu.be/rC9K4sqsgE0](https://youtu.be/rC9K4sqsgE0) I’m curious how others approach **release governance in Kubernetes environments**. Do you rely only on CI/CD pipeline checks, or do you enforce **cluster-level validation before releases**?