DevOps Playbook

Your Role in GitOpsHQ

As a DevOps Engineer, you are the bridge between development intent and production reality. You own the delivery pipeline: creating and managing releases, orchestrating promotions across environments, configuring workloads, integrating CI/CD systems, and ensuring that every deployment follows the governance rules established by the Platform team.

You work closely with developers (who submit configuration changes) and SREs (who monitor runtime health and handle incidents). Your primary concern is controlled, predictable delivery — getting the right changes to the right environments at the right time.

Daily Operating Loop

Follow this sequence to manage your daily delivery operations.

Release Management

Release Lifecycle

Every release passes through a defined lifecycle. Understanding each state helps you manage your delivery pipeline effectively.

Release Best Practices

• One concern per release — A release that updates an image tag should not also change resource limits unless they are related.
• Descriptive titles — Use a format like [service] [action] [version]: payment-api: bump to v2.5.0.
• Include rollback context — Note in the release description what to roll back to if the change causes issues.
• Test in lower environments first — Always deploy to development and staging before production. Use the promotion pipeline to enforce this.

Promotion Pipeline

Promotions move verified changes from one environment to the next.

Promotion Checklist

Before promoting a release to the next environment:

• Verify all pods are healthy in the current environment
• Check for drift — no unexpected changes should be present
• Review any environment-specific value overrides for the target
• Confirm approval requirements for the target environment
• Have a rollback plan ready before promoting to production

Workload Management

Creating a Workload

Workload Updates

When updating a workload's chart version (e.g., upgrading from microservice-base@1.0.0 to 1.1.0):

1. Preview the chart diff to understand what templates changed
2. Check if any new values are required by the new chart version
3. Update the chart version reference in the workload
4. Test in development before promoting the chart upgrade to other environments

CI/CD Integration

Webhook Setup

GitOpsHQ supports inbound webhooks for automated value updates triggered by your CI pipeline.

Example: GitHub Actions Integration

name: Deploy to GitOpsHQ
on:
  push:
    branches: [main]
    
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Build and push image
        run: |
          docker build -t registry.example.com/my-app:${{ github.sha }} .
          docker push registry.example.com/my-app:${{ github.sha }}
      
      - name: Update GitOpsHQ workload
        run: |
          curl -X PATCH \
            https://api.gitopshq.io/v1/projects/${{ vars.PROJECT_ID }}/workloads/${{ vars.WORKLOAD_ID }}/values \
            -H "Authorization: Bearer ${{ secrets.GITOPSHQ_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{"updates": [{"path": "image.tag", "value": "${{ github.sha }}"}]}'

Decision Rules

Follow these rules when making operational decisions:

• Never skip preview for production-scoped changes — Even if you are confident, the preview catches rendering issues that value-level inspection cannot.
• Treat freeze and approval blockers as governance requirements — They exist for a reason. If you believe a freeze or approval is incorrect, escalate to the Platform team rather than working around it.
• Prefer scoped rollouts — Deploy to a canary tenant first, verify, then promote to broader audiences. The promotion pipeline supports this natively.
• Keep rollback readiness visible — Before executing a high-risk promotion, confirm that the previous release is available as a rollback target.
• Document everything — Release notes, approval comments, and deployment outcomes create a knowledge base that helps the entire team learn from past operations.

Handoff Contracts

With Platform Teams

• Request missing permissions or policies as structured governance changes, not ad-hoc exceptions
• Provide feedback on approval policies that create unnecessary bottlenecks
• Report any RBAC gaps that force workarounds

With Developers

• Require clear release descriptions that explain intent, not just changes
• Push back on overly broad releases that mix unrelated changes
• Ensure developers use Environment Compare before submitting releases

With SRE

• Include runtime evidence and rollback plans for risky operations
• Coordinate deployment windows with incident response schedules
• Provide clear escalation paths when deployments need emergency rollback

Key Metrics to Track