Blog

A Technical Guide to Integrating Visual Testing into Your CI/CD Pipeline

C
Cem Bakca
3 min read
A Technical Guide to Integrating Visual Testing into Your CI/CD Pipeline

In modern Software Development Life Cycles (SDLC), manual QA testing is slow, expensive, and error-prone. Especially in scenarios where teams with a Continuous Delivery culture ship code to "Production" dozens of times a day, the only way to ensure safety is to integrate automated visual testing into CI/CD Pipelines.

In this guide, we will examine step-by-step how you can use a "hard-stop" to prevent bugged code from reaching the customer by combining Crawlens Visual Testing automation with GitHub Actions or GitLab.

1. How Does the CI/CD Visual Testing Architecture Work?

The role of visual testing in the CI/CD process is simple: To step in every time a Pull Request (PR) is opened or code is merged into the Main branch, checking if there is a design flaw (Visual Regression).

The flow works as follows:

  1. Commit & Build: A developer pushes a code change to the remote server, and basic tests / build (e.g., npm run build) start.
  2. Preview (Staging) Deployment: Vercel, Netlify, or your own Kubernetes cluster generates a temporary URL specific to that current code.
  3. Visual Check (Crawlens DOM): Your CI/CD pipeline sends this unique URL to the Crawlens API with a "Test This" command.
  4. Catching the Bug (Fail Fast): If Crawlens detects that the Cart button has shifted or its color is corrupted compared to the previous stable version (Baseline), it returns a "Fail" signal to GitHub/GitLab.
  5. Deployment Cancellation: Upon receiving the "Fail" signal, the CI/CD pipeline instantly cancels the code from going live (Production Deploy).

2. GitHub Actions Integration Example

Automating the process is extremely easy on GitHub Actions. Integration can be achieved with a few lines of yaml code using the Crawlens CLI (Command Line Interface) or ready-made GitHub Action packages.

name: Crawlens Visual Test
on: [pull_request]

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

      - name: Await Preview URL
        # Retrieve staging URL from Vercel or a similar platform
        id: wait_for_preview

      - name: Run Crawlens Visual Test
        uses: crawlens/github-action@v1
        with:
          api-token: ${{ secrets.CRAWLENS_API_TOKEN }}
          project-id: 'proj_xyz123'
          test-url: ${{ steps.wait_for_preview.outputs.url }}
          baseline-branch: 'main'

The flow above ensures that the code is verified not only functionally (Unit/E2E) but also from the perspective of the human eye (Visual).

3. Automated Bug Reporting and Approval Flow

When the visual test returns "Fail", the process isn't permanently deadlocked. The Crawlens bot automatically leaves a comment under that Pull Request with the Diff image of the shifted pixels. If the developer or QA engineer confirms that this visual difference is intentional (a new design iteration), they click "Accept Baseline" on Crawlens, and the CI/CD pipeline turns green and continues to production.

Conclusion

Continuous Delivery without automation is an invitation to disaster. If you manage an e-commerce site or a B2B SaaS platform, adding Visual Regression to your GitHub Actions or GitLab pipelines is the most robust way to get your sleep back and protect your brand reputation (UX). Ship your code with the assurance of Crawlens.

Related Posts