Continuous Deployment with GitHub Actions: The Professional Pipeline

We have all the pieces: Docker images (Module 2), Helm Charts (Module 11.2), RBAC security (Module 10.1), and Kubernetes objects. But if you have to run docker build and helm upgrade manually on your laptop every time you push code, you are not a DevOps engineer—you're a bottleneck.

In a professional environment, we use GitHub Actions to create an automated "Conveyor Belt."

Commit: You push Python code to a branch.
Verify: GitHub runs your tests.
Build: GitHub builds a new Docker image.
Secure: GitHub scans the image for vulnerabilities (Module 10.4).
Deploy: GitHub updates your Kubernetes cluster automatically.

In this lesson, we will build this pipeline from scratch. We will learn how to securely handle credentials, how to use the kubectl and helm CLI within an action, and how to implement a safe, automated deployment for your AI agents.

1. The Secrets of the Pipeline: Action Credentials

Before GitHub can talk to your cluster, you must give it the "Keys."

A. The Kubeconfig Secret

You should not give GitHub your cluster-admin credentials. Instead, create a dedicated ServiceAccount for the CI/CD pipeline (Module 10.2). Generate a token for that SA and store it as a GitHub Secret named KUBE_CONFIG.

B. Cloud Registry Credentials

If you are using AWS ECR, you need AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

2. Anatomy of a Release Workflow

We define our pipeline in a YAML file at .github/workflows/deploy.yml.

name: Deploy to Kubernetes

on:
  push:
    branches: [ main ] # Trigger on every push to main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Code
      uses: actions/checkout@v3

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v2

    - name: Login to Amazon ECR
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build and Push
      run: |
        docker build -t <account>.dkr.ecr.us-east-1.amazonaws.com/ai-agent:${{ github.sha }} .
        docker push <account>.dkr.ecr.us-east-1.amazonaws.com/ai-agent:${{ github.sha }}

    - name: Set up Helm
      uses: azure/setup-helm@v3
    
    - name: Deploy with Helm
      run: |
        helm upgrade --install ai-agent ./charts/ai-agent \
          --namespace production \
          --set image.tag=${{ github.sha }}
      env:
        KUBECONFIG_CONTENT: ${{ secrets.KUBE_CONFIG }}

3. The Power of `github.sha`

Notice that we use ${{ github.sha }} as our image tag. This is a 40-character unique hash of your commit.

Traceability: You know exactly which line of code is running in production by looking at the tag.
Immutability: Every build is unique. You never overwrite the same tag twice (Lesson 10.4).

4. Visualizing the Deployment Conveyor Belt

sequenceDiagram
    participant Dev as Developer
    participant Git as GitHub Actions
    participant ECR as Cloud Registry
    participant K8s as Kubernetes Cluster
    
    Dev->>Git: Push Code to Main
    Git->>Git: Run Unit Tests
    Git->>Git: Build Docker Image
    Git->>ECR: Push Image (v123)
    Git->>K8s: Helm Upgrade --set tag=v123
    K8s->>ECR: Pull Image (v123)
    K8s->>K8s: Rolling Update (Old Pods -> New Pods)
    K8s-->>Git: Success!

5. Handling Rollbacks Automatically

A professional pipeline should check if the deployment actually worked.

- name: Verify Rollout
  run: |
    kubectl rollout status deployment/ai-agent --timeout=300s
    if [ $? -ne 0 ]; then
      echo "Deployment failed! Rolling back..."
      helm rollback ai-agent
      exit 1
    fi

By adding this check, you ensure that if your new image has a "CrashLoopBackOff" bug, your CI/CD pipeline will fail, Alerting the team, and production will be safely restored to the last known-good version.

6. AI Implementation: Automating Model Exports

In an LLM pipeline, you might have a step where you "Fine-tune" a model and save the weights to HuggingFace or S3.

The Integrated AI Pipeline:

Step 1: Train/Fine-tune model in an Action runner.
Step 2: Calculate the MD5 hash of the new model weights.
Step 3: Update the MODEL_HASH in your values.yaml in Git.
Step 4: Trigger the Helm deployment.
Step 5: The Pod's Init Container (Module 3.2) sees the new hash, downloads the new weights from S3, verifies them, and starts the container.

This allows your team to iterate on AI models as easily as they iterate on code—with zero manual data movement.

7. Summary and Key Takeaways

Automation: GitHub Actions removes human error from the deployment process.
Secrets: Store Kubeconfig and Cloud keys as GitHub Encrypted Secrets.
SHA Tagging: Use unique commit hashes for your images to ensure traceability.
Verification: Always use kubectl rollout status to verify that the cluster is healthy after an update.
Speed: A code change can go from "Idea" to "Production" in under 5 minutes.

In the next lesson, we will look at an alternative, even more modern way to deploy: GitOps with ArgoCD.

8. SEO Metadata & Keywords

Focus Keywords: GitHub Actions Kubernetes deployment tutorial, automate helm upgrade github actions, github actions ECR push, CI/CD pipeline for AI microservices, K8s deployment verification github actions, kubeconfig github secret.

Meta Description: Master the automation of your Kubernetes cluster. Learn how to build a production-ready CI/CD pipeline using GitHub Actions to securely build, scan, and deploy your AI and web applications with zero manual intervention.