Developer Playbook

Check the Dashboard — Start your day by opening the GitOpsHQ dashboard. Look for any issues with services you own: failed deployments, drift alerts, or pending approvals. The dashboard shows fleet health at a glance — green means healthy, yellow means warning, red means action needed.

Navigate to Your Project — Open the project that contains your services (e.g., payment-service). The project overview shows the current state of each environment: what version is deployed, when it was last updated, and whether there are any pending changes.

Open the In-App Editor — When you need to make a configuration change, use the built-in Git editor. Navigate to the values file for your workload and environment. The editor provides syntax highlighting, YAML validation, and auto-completion for known value paths.

Update Helm Values — Make your changes in the values editor. Common changes include updating the image tag, adjusting replica counts, adding environment variables, or modifying resource limits. The editor shows real-time validation — errors appear inline as you type.

# Example: updating image tag and adding an env var
image:
  repository: registry.example.com/payment-api
  tag: v2.5.0  # updated from v2.4.0

env:
  FEATURE_NEW_CHECKOUT: "true"  # new feature flag

Use HQ Variables for Environment-Specific Values — Instead of hardcoding values that differ between environments, use HQ Variable syntax. This ensures the same template works across dev, staging, and production with appropriate values for each.

database:
  host: "{{hq.var.DATABASE_HOST}}"
  maxConnections: "{{hq.var.DATABASE_MAX_CONNECTIONS}}"

The HQ Variables panel shows you what each variable resolves to in each environment.

Preview Changes with Environment Compare — Before creating a release, use the Environment Compare view to see how your changes will look across environments. This catches mistakes like accidentally setting a production database URL in staging, or forgetting to set a variable for an environment.

Create a Release — Once you are satisfied with the changes, go to Releases → New Release. Select the changes to include, write a descriptive title (e.g., Enable new checkout flow for payment-api v2.5.0), and add release notes explaining what changed and why. Submit the release.

Request Approval — If the release targets an environment with an approval policy (typically staging or production), it enters the approval queue. The assigned reviewers (DevOps, SRE, or team leads) receive a notification. You can see the approval progress in the release detail page.

Monitor Deployment Status — Once approved and deployed, the release timeline shows real-time progress. Watch for the deployment to transition through: Pending → In Progress → Deployed → Healthy. If it stays in "In Progress" for too long or moves to "Failed", investigate immediately.

Use Log Streaming if Issues Arise — If the deployment shows issues, use the diagnostics panel to stream logs from the affected pods. You can filter logs by container, search for error patterns, and correlate log timestamps with the deployment timeline.