HomeInsightsHow to Set Up CI/CD with GitHub Actions — Step by Step

How to Set Up CI/CD with GitHub Actions — Step by Step

Updated 19 Mar 2026

Nilay D

Continuous Integration and Continuous Deployment (CI/CD) have become essential practices for modern software development, enabling teams to automate the building, testing, and deployment of applications.

In today’s fast-paced environment, ensuring that your code changes are continuously validated and released quickly can be a competitive advantage. GitHub Actions—GitHub’s native automation tool—has emerged as a powerful, integrated solution that streamlines your CI/CD pipelines without needing to rely on third-party tools like Jenkins or GitLab CI.

This guide is crafted for Cloud and DevOps Engineers who want to dive deep into GitHub Actions, learn best practices, and explore advanced techniques.

We’ll start with the basics, walk through real YAML examples, expand on security and performance optimizations, and offer insights from real-world use cases.

By the end, you’ll have a robust understanding of how to design, implement, and maintain GitHub Actions pipelines that are both efficient and secure.

Setting Up GitHub Actions for CI/CD

Enabling GitHub Actions in Your Repository

Getting started with GitHub Actions is straightforward. Create a directory named .github/workflows at the root of your repository and add your workflow files in YAML format. These YAML files define your automation steps, including when to run, what tasks to execute, and on which runners.

Example: Basic CI Workflow

name: CI Pipeline

on:

  push:

    branches:

      - main

  pull_request:

    branches:

      - main

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout Repository

        uses: actions/checkout@v3

      - name: Set up Node.js Environment

        uses: actions/setup-node@v3

        with:

          node-version: '16'

      - name: Install Dependencies

        run: npm install

      - name: Run Tests

        run: npm test

Key Points:

• Triggers: The on section sets the events that trigger the workflow (pushes and pull requests on the main branch).
• Jobs & Runners: The build job runs on the ubuntu-latest runner.
• Steps: Each step performs a specific task. We checkout the code, set up Node.js, install dependencies, and run tests.

Deep Dive into GitHub Actions Components

Understanding the Core Concepts

Before building complex pipelines, it’s important to understand the fundamental building blocks of GitHub Actions:

• Workflows: Automated processes defined in YAML files stored in .github/workflows. They are triggered by events like push, pull request, or on a schedule.
• Jobs: Groups of steps that run on the same runner. Jobs can run sequentially or in parallel.
• Steps: Individual commands or actions executed within a job.
• Actions: Reusable modules that perform tasks (e.g., checkout code, set up environments).
• Runners: Machines (either GitHub-hosted or self-hosted) that execute the jobs.

Expanding on YAML Syntax and Best Practices

Writing workflows in YAML can be both powerful and expressive. Here are a few insider tips:

• YAML Formatting: Ensure proper indentation as YAML is whitespace-sensitive. Misalignment can cause subtle bugs.
• Reusability: Use reusable workflows and actions to avoid duplication. For instance, if you have multiple repositories, you can share a common testing or deployment workflow.
• Variables and Secrets: Utilize GitHub Secrets to store sensitive data. Reference them using ${{ secrets.SECRET_NAME }}.

Advanced YAML Example with Caching:

name: CI with Caching

on:

  push:

    branches:

      - main

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout Code

        uses: actions/checkout@v3

      - name: Set up Node.js

        uses: actions/setup-node@v3

        with:

          node-version: '16'

      - name: Cache Node Modules

        uses: actions/cache@v3

        with:

          path: ~/.npm

          key: ${{ runner.os }}-node-${{ hashFiles('/package-lock.json') }}

          restore-keys: |

            ${{ runner.os }}-node-

      - name: Install Dependencies

        run: npm install

      - name: Run Tests

        run: npm test

Insider Tip: Caching dependencies can significantly speed up your builds. Adjust cache keys to reflect changes in dependency files to avoid stale caches.

Building a Complete CI/CD Pipeline with GitHub Actions

Combining CI and CD Workflows

A robust pipeline not only builds and tests your code but also deploys it to various environments. The following example demonstrates how to set up a pipeline that performs both Continuous Integration (CI) and Continuous Deployment (CD).

Example: Full CI/CD Pipeline

name: CI/CD Pipeline

on:

  push:

    branches: [ main ]

  pull_request:

    branches: [ main ]

jobs:

  build:

    runs-on: ubuntu-latest

    outputs:

      build_version: ${{ steps.build.outputs.commit_sha }}

    steps:

      - name: Checkout Code

        uses: actions/checkout@v3

      - name: Set up Node.js

        uses: actions/setup-node@v3

        with:

          node-version: '16'

      - name: Install Dependencies

        run: npm install

      - name: Run Tests

        run: npm test

      - name: Build Application

        id: build

        run: |

          npm run build

          echo "::set-output name=commit_sha::${GITHUB_SHA}"

  deploy:

    needs: build

    runs-on: ubuntu-latest

    if: github.event_name == 'push'

    steps:

      - name: Checkout Code

        uses: actions/checkout@v3

      - name: Deploy to Production

        run: |

          echo "Deploying version ${{ needs.build.outputs.build_version }} to production..."

          # Insert your deployment script/commands here, e.g., uploading artifacts or triggering a deployment job.

Key Points:

• Job Dependencies: The deploy job depends on the build job using the needs keyword. This ensures deployment only occurs after a successful build.
• Conditional Execution: The deployment job only runs on push events to avoid accidental deployments during pull requests.
• Outputs: The build job outputs a variable (commit SHA) that is then used in the deployment job.

Security Best Practices in GitHub Actions

When automating your CI/CD pipeline, security is paramount. Here are some best practices:

Use GitHub Secrets

Store Sensitive Data: Never hardcode credentials or tokens in your YAML files. Store them as GitHub Secrets.

Example:

  env:

  DATABASE_URL: ${{ secrets.DATABASE_URL }}

Limit Permissions

• Minimal Scope: Specify only the permissions required for each workflow. Use the permissions key at the job level.

permissions:

  contents: read

  packages: write

Audit Third-Party Actions

• Trust but Verify: Use actions from trusted sources. Always pin actions to a specific version or commit hash instead of using @latest.

      - uses: actions/checkout@v3

- uses: actions/setup-node@v3

• Review Code: If possible, review the source code of third-party actions to ensure they meet your security standards.

Enable Debugging Carefully

• Controlled Debugging: In case of failures, enable debug logs only temporarily to avoid exposing sensitive information.

  env:

  ACTIONS_STEP_DEBUG: true

Regularly Rotate Secrets

• Update Regularly: Change your secrets periodically and update your workflows accordingly.

Advanced GitHub Actions Techniques

For teams looking to get more out of GitHub Actions, advanced techniques can further optimize your workflows.

Matrix Builds

Matrix builds allow you to run the same job across multiple environments. For example, you can test your application against different Node.js versions.

jobs:

  test:

    runs-on: ubuntu-latest

    strategy:

      matrix:

        node-version: [14, 16, 18]

    steps:

      - uses: actions/checkout@v3

      - name: Set up Node.js

        uses: actions/setup-node@v3

        with:

          node-version: ${{ matrix.node-version }}

      - run: npm install

      - run: npm test

Insider Tip: Matrix builds help ensure compatibility and catch environment-specific bugs early.

Reusable Workflows

Define common workflows once and reuse them across multiple repositories or jobs. This adheres to the DRY (Don't Repeat Yourself) principle and eases maintenance.

Reusable Workflow Example:

Create a file .github/workflows/deploy-template.yml:

name: Deploy Template

on:

  workflow_call:

    inputs:

      environment:

        required: true

        type: string

jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v3

      - name: Deploy to ${{ inputs.environment }}

        run: echo "Deploying to ${{ inputs.environment }} environment..."

        # Add deployment commands here

You can then call this workflow from another workflow:

jobs:

  deploy-production:

    uses: ./.github/workflows/deploy-template.yml

        with:

      environment: production

Caching Strategies

Effective caching minimizes redundant work. Use the actions/cache action to cache dependencies and build outputs.

Dynamic Triggers and Conditionals

Use conditionals (if) to run steps based on specific conditions. This allows for flexible and dynamic workflows.

- name: Run deployment only if tests passed

  if: ${{ success() }}

  run: echo "Proceeding with deployment..."

Deploying Applications with GitHub Actions

Deploying to Cloud Platforms

GitHub Actions can integrate with various cloud providers to deploy applications. Below are a few examples:

1. Deploying to AWS

Example: Deploying to AWS S3

jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v3

      - name: Configure AWS Credentials

        uses: aws-actions/configure-aws-credentials@v1

        with:

          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}

          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

          aws-region: us-east-1

      - name: Deploy to S3

        run: aws s3 sync ./build s3://your-s3-bucket --delete

2. Deploying to Azure

Example: Deploying to Azure Web Apps

jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v3

      - name: Set up Azure Login

        uses: azure/login@v1

        with:

          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy to Azure Web App

        uses: azure/webapps-deploy@v2

        with:

          app-name: 'YourAppName'

          slot-name: 'production'

          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

          package: './build'

3. Deploying to Kubernetes (AKS)

Example: Deploying to AKS

jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v3

      - name: Set up Kubectl

        uses: azure/setup-kubectl@v1

      - name: Get AKS Credentials

        run: az aks get-credentials --resource-group YourResourceGroup --name YourAKSCluster

      - name: Update Deployment Image

        run: kubectl set image deployment/your-deployment your-container=your-registry/your-image:${{ github.sha }}

Real-World Use Case Example

Consider a scenario where a microservices-based application is being continuously deployed. The CI pipeline runs unit tests and integration tests for each microservice, while the CD pipeline deploys the updated containers to a Kubernetes cluster. Monitoring tools integrated into the workflow alert the team via Slack if any deployment fails, ensuring rapid resolution of issues.

Monitoring and Troubleshooting Workflows

Workflow Logs and Insights

GitHub Actions provides detailed logs for each step of your workflow. You can click through failed steps to see error messages and stack traces. Use these logs to diagnose issues.

Enabling Debug Mode

For more detailed logs, enable the debug mode:

  env:

  ACTIONS_STEP_DEBUG: true

Remember to disable this in production to avoid exposing sensitive information.

Integrating Third-Party Monitoring

Tools such as Datadog, New Relic, or Splunk can be integrated with GitHub Actions to provide real-time insights into workflow performance and failures.

Automated Alerts

Set up notifications to alert your team about workflow failures. For example, you can send a Slack notification if the deployment fails:

- name: Slack Notification - Deployment Failed

  if: ${{ failure() }}

  uses: rtCamp/action-slack-notify@v2.2.0

  env:

    SLACK_COLOR: danger

    SLACK_MESSAGE: "Deployment failed for commit ${{ github.sha }}"

    SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}

Conclusion and Next Steps

GitHub Actions has transformed the way DevOps teams build, test, and deploy applications. Its native integration with GitHub, combined with the flexibility of YAML and the vast GitHub Marketplace, makes it an ideal tool for implementing robust CI/CD pipelines.

In this guide, we have:

• Explored the basic and advanced components of GitHub Actions.
• Provided detailed YAML examples to set up CI pipelines, advanced caching, matrix builds, and reusable workflows.
• Discussed security best practices and performance optimizations.
• Illustrated deployment scenarios for AWS, Azure, and Kubernetes.
• Covered strategies for monitoring and troubleshooting your workflows.

Next Steps:

• Experiment: Apply these practices to your own repositories. Start with a basic workflow and gradually integrate advanced techniques like matrix builds and reusable workflows.
• Optimize: Continuously monitor your workflow performance. Use caching and selective triggering to reduce build times.
• Secure: Regularly audit your workflows, secrets, and third-party actions to ensure they meet your security standards.
• Engage: Share your experiences with the community. Whether through blog posts, forums, or GitHub discussions, community feedback can further enhance your CI/CD practices.

By integrating these practices, you can create scalable, secure, and efficient pipelines that not only reduce manual overhead but also enhance the quality and reliability of your software deployments.

Let's book 45-minutes free consultation with our cloud and devops experts to discuss your requirements.

Happy automating!