C
Corporate Hornet
Enhance Harness pipeline governance by enforcing environment progression rules (DEV → QA → STAGE → PROD) while enabling traceability of previous deployments through Change Management tools like ServiceNow.
Problem Statement: Currently, Harness pipelines allow deploying to any environment based on input parameters (SERVICE, ENVIRONMENT, INFRA, GITCOMMIT). However, there is no built-in mechanism to:
* Enforce that a service has successfully deployed to DEV before QA, QA before STAGE, and STAGE before PROD when pipelines are triggered days apart.
* Maintain traceability of previous environment deployments and associate them with pipeline stages/steps for external Change Management systems like ServiceNow.
Proposed Solution:
Deployment History Validation:
* Introduce a precondition step or built-in policy to verify if a service has been successfully deployed to the required previous environment before proceeding.
* Example: If deploying to QA, the pipeline should check if the same GITCOMMIT has been successfully deployed to DEV first.
* Harness should store and validate deployment history (could integrate with existing audit logs or metadata storage).
Deployment Traceability & External Integration
* Add metadata linking pipeline execution IDs, stages, steps, and their respective environments.
* Provide APIs or webhook triggers to update Change Management tools (e.g., ServiceNow) with deployment data.
* Example: A ServiceNow record can contain the pipeline execution from DEV before approving QA deployment.
Time-Gap Resilience
* Since pipelines are executed at different times (days apart), Harness should persist deployment state beyond a single pipeline run.
* Could be stored as pipeline metadata or through an external database integration.
Expected Outcome:
* Governed pipeline flow ensuring controlled environment progression.
* Improved traceability of service deployments across environments.
* Seamless integration with Change Management tools for compliance and approvals.