GitOpsHQ Docs
How-To Guides

Create Release And Deploy

Execute a controlled release from previewed change intent to verified runtime outcome.

Task Outcome

You complete one auditable release cycle with correct approvals, execution controls, and post-deploy verification.

When To Use This Guide

  • Shipping a scoped change to non-production or production.
  • Re-running a blocked release after policy or permission remediation.
  • Standardizing release operation across teams.

Prerequisites

  • Preview is clean and understandable.
  • Environment freeze status is known.
  • Approval owners are available for target environment.

UI Route Map

  1. Open Release Lifecycle.
  2. Create release from current change set.
  3. Review diff and gate signals.
  4. Submit for approval when required.
  5. Execute deploy and verify runtime signals.

Step-By-Step Execution

Create release with a clear title, business context, and target scope.
Review release diff carefully and confirm no unrelated services are included.
Check policy outcomes and approval requirements before requesting execution.
Submit release request and monitor approval gate progress.
Execute deploy when all gates are green and freeze constraints are clear.
Verify runtime health, drift status, and service-level outcomes.
Close release with evidence note for future incident/debug timelines.

Decision Points During Release

  • Prefer smaller service/tenant-scoped releases for risky changes.
  • Separate unrelated changes to keep rollback options clean.
  • Check approver eligibility before starting the request.
  • Never assume request creation means immediate execution.
  • Avoid deploy during unclear freeze windows.
  • Choose execution window with on-call availability.
  • Prepare rollback scope (full/service/field) before execution.
  • Document fallback owner in release note.

Validation Checklist

  • Release diff scope is intentional.
  • Approval gates are satisfied and auditable.
  • Runtime verification is completed after deploy.
  • Evidence note includes who requested, approved, executed, and verified.

Common Failure Modes

  • Release blocked by policy violations not reviewed early.
  • Approvals complete but execution fails due to runtime constraints.
  • Freeze state changed between request and execution.
  • Release note lacks enough context for later incident analysis.

Release Evidence Template

Release title:
Project/environment:
Requester:
Approver(s):
Executor:

Risk summary:
Diff summary:
Runtime verification summary:
Fallback plan:
Post-release follow-up tasks:

Continue With

  1. Promote Between Environments
  2. Execute Rollback Safely
  3. Configure Notifications And Audit Trace

On this page