Part 4: Release Management with Modern Tools

The Chaos Before the System

Three years ago, our release process looked like this: developers would message "Ready to deploy feature X" in Slack, someone would manually update a spreadsheet tracking what's going where, and we'd coordinate deployments through back-and-forth messages. We lost track of which features were in which environment, what issues were blocking releases, and who approved what.

Today, our release management is automated and traceable. Jira tracks what's being released, GitHub Actions builds and tests the code, ArgoCD deploys it to Kubernetes, and everything is auditable. In this part, I'll show you exactly how we integrated these tools to create a seamless release management workflow.

The Release Management Stack

Here's the tool chain I use and why:

• Jira: Release planning, feature tracking, and approval workflows

• GitHub: Source control and CI/CD automation with Actions

• ArgoCD: GitOps-based continuous deployment

• Kubernetes: Container orchestration and deployment platform

• Prometheus/Grafana: Metrics and monitoring (covered in Part 6)

Each tool has a specific role, and they integrate to create a complete release management system.

Jira: Release Planning and Tracking

Jira provides visibility into what's being released, who's working on what, and what's blocking progress.

My Jira Project Structure

I organize Jira around releases, not just features:

Issue Types:

• Epic: Large body of work (e.g., "Payment System Overhaul")

• Story: User-facing feature (e.g., "As a user, I can save payment methods")

• Task: Technical work (e.g., "Add database index for payment queries")

• Bug: Defect to fix

• Release: Container for tracking what goes out together

Custom Fields I Add:

• Target Release Version: Which release version includes this issue

• Environment Status: Which environments have this deployed (Dev/Staging/Prod)

• Deployment Risk: Low/Medium/High

• Rollback Plan: Link to rollback procedure

• Feature Flag: Associated feature flag key (if applicable)

Release Workflow in Jira

My release workflow follows this board structure:

[Backlog] → [Selected for Release] → [In Development] → [Code Review] → [Testing] → [Ready for Release] → [Deployed to Dev] → [Deployed to Staging] → [Deployed to Production] → [Done]

Each column represents a stage in the release lifecycle. Issues automatically move between columns as they progress through GitHub and ArgoCD (through automation I'll show shortly).

Creating a Release in Jira

1. Create a Release Version:
   Project Settings → Releases → Create Release
   - Name: v2.5.0
   - Start date: 2026-02-01
   - Release date: 2026-02-14
   - Description: Payment improvements and bug fixes

2. Associate Issues with Release:
   - Edit issue → Fix Version → v2.5.0
   - Or bulk operation: Select issues → Bulk Change → Edit Issues → Change Fix Versions

3. Track Release Progress:
   - Releases page shows completion percentage
   - Filter: fixVersion = v2.5.0 AND status != Done

Automating Jira with GitHub Actions

I automate Jira updates when code moves through the pipeline:

name: Update Jira on Deployment

on:
  workflow_run:
    workflows: ["Deploy to Environment"]
    types:
      - completed

jobs:
  update-jira:
    runs-on: ubuntu-latest
    steps:
    - name: Extract Jira issue keys from commits
      id: extract
      run: |
        # Get commit messages from the deployment
        COMMITS=$(gh api repos/${{ github.repository }}/commits?sha=${{ github.sha }} --jq '.[].commit.message')
        
        # Extract Jira keys (e.g., PROJ-123)
        ISSUES=$(echo "$COMMITS" | grep -oE '[A-Z]+-[0-9]+' | sort -u)
        
        echo "issues=$ISSUES" >> $GITHUB_OUTPUT
      env:
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        
    - name: Transition Jira issues
      uses: atlassian/gajira-transition@v3
      with:
        issue: ${{ steps.extract.outputs.issues }}
        transition: "Deploy to ${{ github.event.workflow_run.environment }}"
      env:
        JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
        JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
        JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
        
    - name: Add deployment comment
      uses: atlassian/gajira-comment@v3
      with:
        issue: ${{ steps.extract.outputs.issues }}
        comment: |
          Deployed to ${{ github.event.workflow_run.environment }}
          
          Build: [${{ github.sha }}](${{ github.server_url }}/${{ github.repository }}/commit/${{ github.sha }})
          Deployment: ${{ github.event.workflow_run.html_url }}
          Environment: ${{ github.event.workflow_run.environment }}
      env:
        JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
        JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
        JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

What this does:

1. Extracts Jira issue keys from commit messages (e.g., "PROJ-123: Add payment method validation")

2. Automatically transitions issues to "Deployed to Dev/Staging/Production"

3. Adds a comment with deployment details and links

Now developers don't manually update Jira—it happens automatically based on deployments.

Commit Message Convention

For Jira automation to work, we follow this commit convention:

PROJ-123: Add credit card validation

- Implement Luhn algorithm check
- Add validation error messages
- Update API documentation

The first line includes the Jira issue key. GitHub Actions extracts this and updates Jira.

GitHub Actions: CI/CD Automation

GitHub Actions orchestrates the build, test, and deployment pipeline.

Repository Structure for GitOps

I maintain two repositories:

Application Repository (myapp):

• Application source code

• Dockerfile

• Unit and integration tests

• GitHub Actions workflows for CI/CD

GitOps Repository (gitops-infra):

• Kubernetes manifests

• Kustomize overlays for each environment

• ArgoCD application definitions

• Infrastructure as Code

This separation follows GitOps principles—application code and deployment configuration are versioned separately.

Application Repository CI Workflow

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run tests
      run: npm test
    
    - name: Build application
      run: npm run build

  build-image:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/develop'
    
    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v3
    
    - name: Log in to GitHub Container Registry
      uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
    
    - name: Extract metadata
      id: meta
      uses: docker/metadata-action@v5
      with:
        images: ghcr.io/${{ github.repository }}
        tags: |
          type=sha,prefix={{branch}}-
          type=ref,event=branch
          type=semver,pattern={{version}}
    
    - name: Build and push
      uses: docker/build-push-action@v5
      with:
        context: .
        push: true
        tags: ${{ steps.meta.outputs.tags }}
        cache-from: type=gha
        cache-to: type=gha,mode=max

  update-gitops:
    needs: build-image
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout GitOps repository
      uses: actions/checkout@v4
      with:
        repository: myorg/gitops-infra
        token: ${{ secrets.GITOPS_PAT }}
    
    - name: Update image tag in appropriate overlay
      run: |
        ENVIRONMENT="development"
        if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
          ENVIRONMENT="staging"
        fi
        
        cd apps/myapp/overlays/$ENVIRONMENT
        kustomize edit set image myapp=ghcr.io/${{ github.repository }}:${{ github.sha }}
    
    - name: Commit and push
      run: |
        git config user.name "GitHub Actions"
        git config user.email "[email protected]"
        git add .
        git commit -m "Update myapp image to ${{ github.sha }} in $ENVIRONMENT"
        git push

Key points:

1. CI runs tests first

2. On merge to main or develop, builds container image

3. Updates GitOps repository with new image tag

4. ArgoCD detects the change and deploys (shown next)

ArgoCD: GitOps Continuous Deployment

ArgoCD continuously monitors the GitOps repository and automatically syncs changes to Kubernetes clusters.

Installing ArgoCD

# Create namespace
kubectl create namespace argocd

# Install ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Expose ArgoCD UI (in production, use Ingress with TLS)
kubectl port-forward svc/argocd-server -n argocd 8080:443

# Get initial admin password
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Access ArgoCD UI at https://localhost:8080 and log in with username admin and the password from above.

GitOps Repository Structure

gitops-infra/
├── apps/
│   ├── myapp/
│   │   ├── base/
│   │   │   ├── kustomization.yaml
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── configmap.yaml
│   │   └── overlays/
│   │       ├── development/
│   │       │   ├── kustomization.yaml
│   │       │   └── patches.yaml
│   │       ├── staging/
│   │       │   ├── kustomization.yaml
│   │       │   └── patches.yaml
│   │       └── production/
│   │           ├── kustomization.yaml
│   │           ├── patches.yaml
│   │           └── rollout.yaml
│   └── other-app/
└── argocd/
    └── applications/
        ├── myapp-dev.yaml
        ├── myapp-staging.yaml
        └── myapp-production.yaml

Kubernetes Base Manifest

# apps/myapp/base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: ghcr.io/myorg/myapp:latest  # Overridden by kustomize
        ports:
        - containerPort: 8080
        env:
        - name: NODE_ENV
          value: "production"
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:            path: /health/live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP

Development Overlay

# apps/myapp/overlays/development/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: development

resources:
- ../../base

images:
- name: ghcr.io/myorg/myapp
  newTag: develop-a1b2c3d  # Updated by GitHub Actions

replicas:
- name: myapp
  count: 2  # Fewer replicas in dev

patches:
- path: patches.yaml

# apps/myapp/overlays/development/patches.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
      - name: myapp
        env:
        - name: LOG_LEVEL
          value: "debug"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: database-credentials-dev
              key: url

Production Overlay with Canary

# apps/myapp/overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: production

resources:
- ../../base
- rollout.yaml  # Use Argo Rollout instead of Deployment

images:
- name: ghcr.io/myorg/myapp
  newTag: main-x9y8z7w  # Updated by GitHub Actions

replicas:
- name: myapp
  count: 10  # More replicas in production

# apps/myapp/overlays/production/rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 25
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}
      - setWeight: 75
      - pause: {duration: 5m}
      analysis:
        templates:
        - templateName: error-rate-analysis
        startingStep: 1
  selector:
    matchLabels:
      app: myapp
  template:
    # Same as deployment template

ArgoCD Application Definition

# argocd/applications/myapp-production.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-production
  namespace: argocd
spec:
  project: default
  
  source:
    repoURL: https://github.com/myorg/gitops-infra
    targetRevision: main
    path: apps/myapp/overlays/production
  
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  
  syncPolicy:
    automated:
      prune: true      # Remove resources not in git
      selfHeal: true   # Revert manual changes
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m
  
  # Health assessment during sync
  ignoreDifferences:
  - group: argoproj.io
    kind: Rollout
    jsonPointers:
    - /spec/replicas  # Ignore HPA-managed replicas

Apply the ArgoCD application:

kubectl apply -f argocd/applications/myapp-production.yaml

ArgoCD Synchronization Workflow

Here's what happens when GitHub Actions updates the image tag:

1. GitHub Actions merges PR to main

2. CI pipeline builds container image tagged with commit SHA

3. GitHub Actions updates gitops-infra repository:

   • Runs kustomize edit set image in staging overlay

   • Commits and pushes change

4. ArgoCD detects change in Git repository (polls every 3 minutes by default)

5. ArgoCD compares desired state (Git) with actual state (Kubernetes)

6. ArgoCD syncs the difference:

   • For staging: Rolling update deployment

   • For production: Canary rollout with Argo Rollouts

7. ArgoCD monitors health checks until all pods are healthy

8. GitHub Actions (via webhook) receives sync status and updates Jira

Monitoring ArgoCD

# Watch application sync status
argocd app get myapp-production

# View sync history
argocd app history myapp-production

# Manually trigger sync if needed
argocd app sync myapp-production

# View pod logs from ArgoCD
argocd app logs myapp-production

# Rollback to previous version
argocd app rollback myapp-production

ArgoCD Notifications

I configure ArgoCD to notify Slack when deployments happen or fail:

# argocd-notifications-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: $slack-token
  
  trigger.on-deployed: |
    - when: app.status.operationState.phase in ['Succeeded']
      send: [app-deployed]
  
  trigger.on-health-degraded: |
    - when: app.status.health.status == 'Degraded'
      send: [app-health-degraded]
  
  template.app-deployed: |
    message: |
      Application {{.app.metadata.name}} deployed successfully!
      Revision: {{.app.status.sync.revision}}
      Environment: {{.app.spec.destination.namespace}}
    slack:
      attachments: |
        [{
          "color": "good",
          "title": "{{.app.metadata.name}}",
          "title_link": "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}",
          "fields": [{
            "title": "Sync Status",
            "value": "{{.app.status.sync.status}}",
            "short": true
          }, {
            "title": "Repository",
            "value": "{{.app.spec.source.repoURL}}",
            "short": true
          }]
        }]
  
  template.app-health-degraded: |
    message: |
      ⚠️ Application {{.app.metadata.name}} health is degraded!
    slack:
      attachments: |
        [{
          "color": "danger",
          "title": "{{.app.metadata.name}}",
          "title_link": "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}",
          "fields": [{
            "title": "Health Status",
            "value": "{{.app.status.health.status}}",
            "short": true
          }]
        }]

# argocd-notifications-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: argocd-notifications-secret
  namespace: argocd
stringData:
  slack-token: xoxb-your-slack-bot-token

Subscribe the production app to notifications:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-production
  annotations:
    notifications.argoproj.io/subscribe.on-deployed.slack: releases-channel
    notifications.argoproj.io/subscribe.on-health-degraded.slack: incidents-channel
# ... rest of application spec

Kubernetes: The Deployment Platform

Kubernetes orchestrates the containers, manages health checks, and handles rollouts.

Namespace Isolation

I isolate environments using namespaces:

kubectl create namespace development
kubectl create namespace staging
kubectl create namespace production

# Label namespaces for organizational policies
kubectl label namespace production environment=production tier=critical
kubectl label namespace staging environment=staging tier=non-critical
kubectl label namespace development environment=development tier=non-critical

Resource Quotas

To prevent resource exhaustion, I set quotas per namespace:

# resource-quota-production.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: production
spec:
  hard:
    requests.cpu: "50"
    requests.memory: 100Gi
    limits.cpu: "100"
    limits.memory: 200Gi
    persistentvolumeclaims: "20"
    pods: "50"

Network Policies

Restrict traffic between namespaces:

# network-policy-production.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
    ports:
    - protocol: TCP
      port: 8080

Secrets Management

I use External Secrets Operator to sync secrets from AWS Secrets Manager:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secretsmanager
  namespace: production
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-west-2
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: SecretStore
  target:
    name: database-credentials-prod
    creationPolicy: Owner
  data:
  - secretKey: url
    remoteRef:
      key: prod/database/url
  - secretKey: username
    remoteRef:
      key: prod/database/username
  - secretKey: password
    remoteRef:
      key: prod/database/password

Putting It All Together: End-to-End Flow

Here's the complete flow from code commit to production:

1. Developer creates feature branch, includes Jira key in commits (PROJ-123: Add feature)

2. Developer opens pull request in GitHub

3. GitHub Actions runs CI pipeline:

   • Unit tests

   • Integration tests

   • Code quality checks

   • Security scans

4. Team member reviews and approves PR

5. Developer merges PR to main

6. GitHub Actions CD pipeline:

   • Builds container image tagged with commit SHA

   • Pushes image to GitHub Container Registry

   • Updates gitops-infra repository staging overlay with new image tag

   • Updates Jira issue: transitions to "Deployed to Staging"

7. ArgoCD detects change in gitops-infra:

   • Syncs new image to staging namespace

   • Performs rolling update

   • Waits for health checks

8. GitHub Actions runs smoke tests against staging

9. Tech lead approves production deployment in GitHub UI

10. GitHub Actions:

    • Updates gitops-infra repository production overlay

    • Updates Jira issue: transitions to "Deployed to Production"

11. ArgoCD:

    • Syncs new image to production namespace

    • Starts canary rollout (10% → 25% → 50% → 75% → 100%)

    • Monitors Prometheus metrics during rollout

    • Automatically rolls back if error rate spikes

12. ArgoCD posts notification to Slack: "myapp-production deployed successfully"

13. Jira issue automatically marked as Done

All of this happens without manual intervention beyond the approval step.

Key Takeaways

1. Separate application code from deployment manifests: Use two repositories—one for code, one for Kubernetes manifests

2. Automate Jira updates: Extract issue keys from commits and update Jira automatically

3. GitOps with ArgoCD: Git is the single source of truth for what's deployed

4. Environment-specific overlays: Use Kustomize to customize deployments per environment

5. Progressive delivery in production: Use Argo Rollouts for canary deployments with automatic rollback

6. Integrate notifications: Keep team informed without requiring them to check multiple tools

In the next part, we'll establish standards for reproducible deployments and ensure consistency across environments.

---

Previous: Part 3: CI/CD Pipeline Best Practices - Testing Gates and Promotion Flows Next: Part 5: Standardization and Reproducible Deployments