CI/CD Pipeline Visualizer

This free CI/CD pipeline visualizer shows how code moves from commit to production: the build, test and deploy stages, where automated tests run, and how quality gates and artifacts fit in. It is built for SDETs who need to explain where their tests live in a pipeline — a question that comes up in almost every senior automation interview.

↓ Open the tool

Continuous integration vs continuous delivery

Continuous integration means every commit is automatically built and tested, so integration problems surface within minutes. Continuous delivery extends that so a passing build is always deployable, and continuous deployment pushes it to production automatically. Knowing which term means what is a frequent interview trap.

Where automated tests run in a pipeline

A healthy pipeline runs tests in layers: fast unit tests on every commit, then API/integration tests, then a smaller set of UI/end-to-end tests — the test pyramid. Running the slow UI tests only after the fast ones pass keeps feedback quick and CI costs down.

Quality gates and artifacts

A quality gate fails the pipeline if tests fail or coverage/quality thresholds are not met, so broken code cannot advance. An artifact (a jar, a Docker image, a test report) is produced once and promoted through environments unchanged, which is why you build once and deploy the same artifact everywhere.

Jenkins vs GitHub Actions

Both orchestrate the same stages. Jenkins is a self-hosted server configured with a Jenkinsfile and huge plugin ecosystem. GitHub Actions is hosted and configured with YAML workflows right next to your code, with less to maintain. For a portfolio project, Actions is usually the faster path to a green pipeline.

How to use this tool

Follow a commit as it triggers the pipeline in the tool.
Watch the build stage produce an artifact.
See unit, API and UI tests run in sequence, with a gate after each.
Trigger a test failure and watch the gate stop the deploy.

Worked example

A minimal GitHub Actions workflow that builds and runs tests on every push:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "17"
      - run: mvn -B test

Every push checks out the code, sets up Java, and runs the Maven test suite.

Common mistakes to avoid

Running the full slow UI suite on every commit instead of gating it behind fast tests.
Building a fresh artifact per environment instead of promoting one build.
Letting flaky tests stay in the pipeline until the team ignores failures.
No quality gate, so a red build can still deploy.

Frequently asked questions

What is the difference between CI and CD?

CI (continuous integration) automatically builds and tests every commit; CD (continuous delivery/deployment) keeps a passing build always deployable and can push it to production automatically.

Where do automated tests run in a CI/CD pipeline?

In layers — fast unit tests first, then API/integration tests, then a smaller UI/end-to-end suite — so feedback stays quick and costs stay low.

What is a quality gate?

A checkpoint that fails the pipeline if tests fail or quality thresholds are not met, preventing broken code from advancing.

Jenkins or GitHub Actions?

Jenkins is self-hosted and highly extensible via plugins and a Jenkinsfile; GitHub Actions is hosted and configured in YAML beside your code with less maintenance. Both run the same build-test-deploy stages.

Is this CI/CD tool free?

Yes, it runs in your browser with nothing to install and is free for learning and interview prep.