CI/CD can sound like something reserved for large engineering teams running complex infrastructure. In reality, you can start learning the fundamentals with a relatively simple workflow.

A basic CI/CD pipeline might look like this:

Code push
   ↓
Workflow triggered
   ↓
Dependencies installed
   ↓
Code checked
   ↓
Tests run
   ↓
Application built
   ↓
Deployment

The important part is not how complicated your first pipeline is. It is understanding why each stage exists and what happens when something fails.

In this guide, you’ll learn how to set up the structure of your first CI/CD pipeline using GitHub Actions. We’ll cover Continuous Integration, Continuous Delivery and Continuous Deployment, workflow triggers, jobs, automated testing, linting, builds, secrets and deployment.

By the end, you should understand how the pieces fit together—and, more importantly, what you can build to demonstrate that knowledge in your software development portfolio.

Note: This guide focuses on understanding and building the foundation of a CI/CD pipeline. The exact commands and deployment configuration will vary depending on your programming language, framework and hosting environment.

What Is a CI/CD Pipeline?

CI/CD stands for Continuous Integration and Continuous Delivery or Continuous Deployment.

A CI/CD pipeline is an automated process that helps move code through stages such as validation, testing, building and deployment.

Instead of relying entirely on developers to manually perform these tasks every time code changes, a pipeline can run predefined checks automatically.

For example:

Developer changes code
        ↓
Code is pushed to GitHub
        ↓
CI/CD workflow starts
        ↓
Tests run automatically
        ↓
Build runs
        ↓
Code is ready for deployment

CI/CD is not one specific tool. It is an approach to automating parts of the software development lifecycle.

What Is Continuous Integration?

Continuous Integration (CI) focuses on regularly integrating code changes and validating them automatically.

Imagine you make a change to an application and push it to a repository. A CI workflow can automatically:

• install dependencies
• run linting
• execute automated tests
• check whether the application builds successfully

If one of those stages fails, the workflow can report the failure before the code moves further through your delivery process.

A simple example is:

You push new code to GitHub. Instead of remembering to manually run every check, your CI workflow runs the relevant checks automatically.

This does not guarantee that your application is perfect. It does, however, make validation more consistent.

What Is Continuous Delivery?

Continuous Delivery takes the process further by keeping validated code in a state where it can be released.

The pipeline might automatically test and build the application, then prepare it for deployment.

A production release can still require human approval.

For example:

Code pushed
   ↓
Tests pass
   ↓
Build succeeds
   ↓
Application deployed to staging
   ↓
Human approval
   ↓
Production deployment

What Is Continuous Deployment?

Continuous Deployment means successful changes can automatically move into production once the required pipeline stages pass.

There may be no manual approval between a successful pipeline and deployment.

That distinction matters:

Continuous Integration	Continuous Delivery	Continuous Deployment
Code is automatically validated	Code is kept ready for release	Successful code is automatically released
Focuses on integration, testing and validation	A release may still require approval	Deployment can happen without manual release approval
Helps detect problems earlier	Helps reduce release effort	Automates the release process further

Don’t use the terms interchangeably. A pipeline can implement CI without automatically deploying anything to production.

How Does a CI/CD Pipeline Work?

While pipelines differ between organisations and projects, a beginner-friendly workflow often follows this sequence:

Developer pushes code
        ↓
GitHub Actions workflow starts
        ↓
Dependencies are installed
        ↓
Linting runs
        ↓
Automated tests run
        ↓
Application is built
        ↓
Deployment conditions are checked
        ↓
Application is deployed

Let’s break that down.

1. A Trigger Starts the Pipeline

A pipeline needs an event that tells it to run.

Common GitHub Actions triggers include:

• a push
• a pull_request
• a manually triggered workflow

GitHub Actions workflows are configurable automated processes defined in YAML files. They can contain one or more jobs and run when configured events occur. (GitHub Docs)

For example, you might decide:

Run the CI workflow every time someone pushes code to the main branch.

2. The Application Is Prepared

The workflow runner may need to:

• check out the repository
• install a programming language or runtime
• install project dependencies

This prepares the environment to run the next stages.

3. Code Quality Checks Run

Linting can check code against predefined rules and help identify certain issues before deployment.

For example, a pipeline may run:

npm run lint

If linting fails, you may want the pipeline to stop rather than continue to the build or deployment stages.

4. Automated Tests Run

Tests help verify that parts of the application behave as expected.

Depending on the project, this could include:

• unit tests
• integration tests
• other automated checks

5. The Application Is Built

The pipeline verifies that the application can be prepared for its intended environment.

Depending on the technology, a build might involve:

• compiling source code
• generating production assets
• packaging an application
• creating a container image

6. Deployment Happens

If the previous stages succeed, the application may be deployed to an environment such as:

Development
     ↓
Staging
     ↓
Production

For a beginner, it is useful to understand the entire flow even if your first workflow only automates testing and building.

Why Use GitHub Actions for Your First CI/CD Pipeline?

GitHub Actions is a practical place to start because workflows live alongside your project’s code.

GitHub describes a workflow as an automated process made up of one or more jobs. Workflows are defined using YAML files in the .github/workflows directory, and jobs run on runner machines through a series of steps. (GitHub Docs)

For a beginner, this makes the workflow easier to connect to the project itself.

You can see:

Your application code
        +
Your Git history
        +
Your CI/CD workflow
        =
One project repository

GitHub Actions can be used to automate tasks such as:

• building and testing pull requests
• running scripts
• automating repetitive development tasks
• deploying applications

The goal of your first pipeline is not to use every available feature. Start by understanding the basic building blocks.

What You Need Before Setting Up a CI/CD Pipeline

Before writing a workflow, you should ideally have:

• A GitHub account
• A GitHub repository
• A project with code
• A way to run the project locally
• At least one automated test where applicable
• A basic understanding of Git
• A package manager appropriate for your project
• A deployment destination if you plan to add deployment

Your project might use:

• JavaScript or Node.js
• Python
• Java
• PHP
• .NET
• another supported technology

The exact commands will change, but the core pipeline concept remains similar.

Before automating a process, make sure you understand how to run it locally. If you cannot explain how your application is tested or built manually, blindly automating it in YAML will make debugging much harder.

How to Set Up a CI/CD Pipeline with GitHub Actions

Step 1: Decide What Your Pipeline Should Do

This is where many beginners go wrong.

They search for a GitHub Actions example, copy the YAML, make small changes until it stops producing errors, and then claim they have built a CI/CD pipeline.

That is not a strong understanding of CI/CD.

Before writing any configuration, define the process you want to automate.

For example:

When code is pushed to the main branch:

1. Install dependencies
2. Run linting
3. Run automated tests
4. Build the application
5. Deploy only if the required stages succeed

Your workflow can then follow this blueprint:

Trigger → Validate → Test → Build → Deploy

This is your pipeline design.

The YAML should implement a process you understand—not create a process you cannot explain.

Step 2: Create a GitHub Actions Workflow

GitHub Actions workflow files are stored in:

.github/workflows/

Workflow files use either the .yml or .yaml extension. (GitHub Docs)

For example:

.github/
└── workflows/
    └── ci.yml

A basic workflow contains several important concepts.

name

This gives the workflow a recognisable name.

For example:

name: CI Pipeline

on

This defines the event or events that trigger the workflow.

For example:

on:
  push:

You can configure workflows around repository activity, manual events and other supported triggers. (GitHub Docs)

jobs

Jobs define the units of work your workflow performs.

For example:

jobs:
  test:

runs-on

A job needs an environment in which to run.

For example:

runs-on: ubuntu-latest

steps

Steps are the individual actions or commands within a job.

A step might:

• check out your repository
• set up a runtime
• install dependencies
• run a command
• execute a reusable action

GitHub’s workflow model is built around these components: events trigger workflows, workflows contain jobs, jobs run on runners, and jobs contain one or more steps. (GitHub Docs)

Step 3: Create a Basic CI Workflow

For this example, let’s use a generic Node.js project.

Your actual commands may differ.

A simplified workflow could look like this:

name: CI Pipeline

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v6

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Run linting
        run: npm run lint

      - name: Run tests
        run: npm test

This is deliberately simple.

Let’s examine what happens.

Check Out the Repository

The runner starts with its own environment. If your workflow needs to work with your project’s files, the repository needs to be checked out onto that runner.

GitHub’s documentation uses actions/checkout for this purpose when a workflow needs access to repository code. (GitHub Docs)

Set Up the Runtime

The workflow prepares the environment with the required version of Node.js.

Other projects might instead set up:

• Python
• Java
• PHP
• .NET

Use the setup process appropriate for your technology.

Install Dependencies

The workflow installs the dependencies required by the project.

In this example:

npm ci

The important point is that your pipeline should reproduce the steps needed to validate the project in a clean environment.

Run Linting

The workflow runs the project’s linting command.

If the command fails, the job can fail.

That gives you an automated quality gate.

Run Tests

The final step runs your automated tests.

If a test fails, the workflow result will show that the validation was unsuccessful.

That is the foundation of Continuous Integration.

Practical next step: Once you understand this structure, apply it to a real project through the CI/CD Pipeline Setup task on Graduates Hub. The objective is not just to have a workflow file—it is to create and document evidence that you understand how the pipeline works.

Step 4: Run Automated Tests

Automated testing is one of the main reasons to introduce CI.

Without CI, a workflow might look like this:

Developer changes code
        ↓
Developer forgets to run tests
        ↓
Code is shared or deployed
        ↓
Problem is discovered later

With CI:

Developer changes code
        ↓
Code is pushed
        ↓
Pipeline runs tests
        ↓
Failure is reported
        ↓
Developer investigates and fixes the issue

The exact tests depend on the project.

Unit Tests

Unit tests generally focus on smaller units of functionality.

For example, you might test whether a function correctly:

• calculates a total
• validates an email address
• formats a date

Integration Tests

Integration tests can check whether different parts of an application work together correctly.

For example:

Application
    ↓
API request
    ↓
Database interaction
    ↓
Expected response

You do not need to implement every possible type of test in your first pipeline.

Start with the tests your project actually uses.

A CI pipeline should validate meaningful parts of the project rather than run checks simply because a tutorial included them.

If you want to develop your testing skills alongside CI/CD, Graduates Hub also includes software development tasks focused on quality assurance and testing, such as the Exploratory Test Charter & Session Report. It is a different type of testing exercise, but it reinforces an important principle: testing should produce evidence of what was checked, what was found and how you investigated it.

Step 5: Add Linting and Code Quality Checks

Linting helps analyse code against predefined rules.

A typical pipeline flow might be:

Lint fails
   ↓
Pipeline fails
   ↓
Developer fixes the issue
   ↓
New code is pushed
   ↓
Pipeline runs again

This can help prevent some issues from progressing to later stages.

For example, it may be wasteful to run a lengthy deployment process when the code has already failed a basic validation check.

A common order is:

Install dependencies
        ↓
Lint
        ↓
Test
        ↓
Build
        ↓
Deploy

Your order may vary depending on your project.

The key is to decide what should happen when a stage fails.

For a basic pipeline, a reasonable rule is:

If a critical validation step fails, do not continue to the next critical stage.

Step 6: Build Your Application

A successful test run does not necessarily mean your application can be successfully built.

Your build stage might:

• compile source code
• generate production-ready files
• package an application
• create static assets
• build a container image

For example:

- name: Build application
  run: npm run build

If your project has a build process, validating it inside CI can help identify problems before deployment.

Your pipeline then becomes:

Code pushed
     ↓
Linting passes
     ↓
Tests pass
     ↓
Build succeeds
     ↓
Ready for next stage

This is why a CI/CD pipeline should be designed as a series of meaningful checks rather than a single block of commands.

Step 7: Add Deployment to Your Pipeline

Once you can reliably validate and build your application, you can begin thinking about deployment.

There are several approaches.

Automated Deployment

A successful workflow deploys the application automatically.

For example:

Push to main branch
       ↓
Tests pass
       ↓
Build succeeds
       ↓
Deploy automatically

Deployment with Approval

The pipeline completes validation and prepares the release, but production deployment requires approval.

Tests pass
     ↓
Build succeeds
     ↓
Staging deployment
     ↓
Approval
     ↓
Production deployment

Multi-Environment Deployment

More mature workflows may move changes through different environments:

Development
     ↓
Staging
     ↓
Production

Each environment can have different configuration and safeguards.

For your first CI/CD pipeline, you do not need to build an enterprise deployment system.

However, you should understand that production deployment is not simply:

“The build passed, so push everything live.”

Depending on the application, you may need to consider:

• environment variables
• deployment credentials
• secrets
• approvals
• deployment protection rules
• rollback planning

GitHub Actions supports deployment environments and related configuration such as environment secrets and protection rules. (GitHub Docs)

How to Manage Secrets in a CI/CD Pipeline

One of the easiest ways to create a security problem is to put sensitive credentials directly into your repository.

Never treat this as a valid shortcut:

password: my-production-password

Sensitive information can include:

• API keys
• passwords
• deployment tokens
• cloud credentials
• private keys

GitHub Actions provides secrets that can be stored at repository, environment or organisation levels and accessed by workflows when explicitly referenced. GitHub also recommends applying the principle of minimum permissions when creating credentials. (GitHub Docs)

The practical rule for beginners is simple:

Do not hard-code production passwords, API keys or private credentials into your workflow or commit them to a repository.

Secrets management becomes increasingly important as your pipeline begins interacting with external services and deployment environments.

A Simple CI/CD Pipeline Architecture for Beginners

Here is a simplified view of how the pieces fit together:

                ┌─────────────────┐
                │ Developer Pushes │
                │      Code        │
                └────────┬────────┘
                         ↓
                ┌─────────────────┐
                │ GitHub Actions  │
                │    Triggered    │
                └────────┬────────┘
                         ↓
                  ┌────────────┐
                  │   Linting  │
                  └─────┬──────┘
                        ↓
                  ┌────────────┐
                  │   Testing  │
                  └─────┬──────┘
                        ↓
                  ┌────────────┐
                  │   Build    │
                  └─────┬──────┘
                        ↓
                  ┌────────────┐
                  │   Deploy   │
                  └────────────┘

The stages may differ, but the central idea remains:

Automate the process and stop to investigate when something important fails.

For example:

Tests fail
    ↓
Build does not proceed
    ↓
Deployment does not proceed
    ↓
Developer investigates
    ↓
Code is fixed
    ↓
Pipeline runs again

That feedback loop is one of the practical benefits of CI/CD.

Common CI/CD Pipeline Mistakes Beginners Make

1. Deploying Code Without Automated Testing

If your pipeline deploys code without meaningful validation, you lose one of the major benefits of CI.

Start with tests that are relevant to your application.

The goal is not to have the word “test” in your pipeline. The goal is to verify something useful.

2. Putting Secrets Directly in the Repository

Credentials should not be treated as ordinary configuration values.

Use an appropriate secrets-management mechanism and restrict permissions as much as reasonably possible. (GitHub Docs)

3. Building One Massive Workflow Without Understanding It

A huge YAML file copied from several tutorials can be difficult to maintain and nearly impossible to explain.

Start with a workflow you understand:

Trigger
   ↓
Install
   ↓
Test
   ↓
Build

Then add complexity when there is a reason.

4. Only Testing After Deployment

Testing after deployment can be useful, but relying on that alone can allow avoidable problems to move too far through your process.

Validate earlier where appropriate.

5. Ignoring Pipeline Failures

A red workflow is not just an inconvenience to rerun until it turns green.

Read the logs.

Identify:

• which job failed
• which step failed
• what command produced the error
• whether the issue is in the application or workflow configuration

6. Assuming a Successful Build Means a Safe Deployment

A build can succeed while other deployment concerns still exist.

For example:

• the wrong environment variables may be configured
• a deployment credential may be invalid
• the application may behave differently in production
• a database migration may introduce problems

CI/CD reduces manual work and improves consistency, but it does not remove the need for sound engineering decisions.

7. Building a Pipeline You Cannot Explain

This is the biggest problem if you’re learning CI/CD to strengthen your portfolio.

Do not simply copy a workflow and say:

“I built CI/CD.”

You should be able to explain:

• what triggers the workflow
• what each job does
• why each step exists
• what happens when a stage fails
• why your deployment conditions exist

That is the difference between possessing a file and demonstrating a skill.

How to Test and Debug Your CI/CD Pipeline

CI/CD pipelines are software configuration. Expect to debug them.

A practical process is:

1. Make a small change
2. Push the change
3. Check the workflow result
4. Open the failed job
5. Review the logs
6. Identify the failed step
7. Fix the underlying problem
8. Push the updated code
9. Review the new workflow run

GitHub Actions provides workflow logs and workflow commands that can support debugging, warnings, errors, environment variables and other workflow behaviour. (GitHub Docs)

Common causes of failure include:

Dependency Problems

The workflow may be unable to install the dependencies your application needs.

Runtime Differences

Your local environment may use a different runtime version from the workflow runner.

Test Failures

The application may contain a genuine regression.

Configuration Errors

YAML is sensitive to structure and indentation. A configuration mistake can prevent a workflow from behaving as expected.

Environment Problems

Your workflow may depend on configuration or credentials that are missing or incorrectly configured.

Treat each failure as information.

The objective is not to make the pipeline look successful at all costs. The objective is to understand what it is checking and why it failed.

What Should You Learn After Building Your First CI/CD Pipeline?

Your first pipeline is the foundation.

Once you understand triggers, jobs, steps, testing and builds, you can explore more advanced areas.

Multiple Environments

Learn how development, staging and production environments can have different workflows and controls.

Deployment Approvals

Understand when human approval may be appropriate before a production release.

Docker and Container Builds

You can extend a pipeline to build and validate container images.

Secrets Management

Learn how to provide sensitive configuration to workflows without committing credentials to your codebase.

Rollback Strategies

Consider what happens when a deployment introduces a serious problem.

Deployment Logging and Monitoring

A pipeline should not be the end of your visibility into a deployment. Learn how to track what was deployed and investigate failures.

Zero-Downtime Deployment

Explore deployment strategies designed to reduce or avoid service interruption.

These are useful next steps because they take you beyond a basic “run tests on push” workflow.

If you want to demonstrate those skills in a structured project rather than stopping at a tutorial, the CI/CD Pipeline Setup portfolio task is the logical next step. It is designed around practical pipeline concepts including workflows, environments, testing and deployment-related considerations.

Put Your CI/CD Skills Into Practice

Reading about CI/CD is useful.

But if you’re building a software development portfolio, understanding a concept privately is different from having evidence that you can apply it.

A practical project gives you something you can:

• build
• document
• explain
• improve
• include as evidence of your technical skills

For CI/CD, don’t stop after copying a YAML example.

Take the concepts from this guide and complete a project where you need to think through the pipeline yourself.

Your next step: Build a CI/CD pipeline for your portfolio.

Document what you built and make sure you can explain the decisions behind it.

That is more useful than claiming familiarity with CI/CD without being able to show how you applied it.

Frequently Asked Questions

Can beginners learn CI/CD?

Yes. Start with a simple workflow that automates a small number of tasks, such as installing dependencies and running tests.

Once you understand the workflow structure, you can add linting, builds and deployment stages.

Is GitHub Actions suitable for learning CI/CD?

Yes. It allows workflows to be defined in a repository using YAML and triggered by configured events. A workflow can contain jobs, and jobs contain steps that run on a runner environment. (GitHub Docs)

Do I Need Docker to Learn CI/CD?

No.

Docker can be part of a CI/CD workflow, particularly when building and deploying containerised applications, but you can learn the fundamentals of CI/CD without it.

Start by automating meaningful tasks such as testing, linting and building.

What Is the Easiest CI/CD Pipeline to Build?

A good starting point is a pipeline that:

1. Runs when code is pushed
2. Checks out the repository
3. Installs dependencies
4. Runs linting
5. Runs automated tests

You can then add a build stage and deployment as your understanding develops.

Should a CI/CD Pipeline Deploy Directly to Production?

Not necessarily.

Some teams use automated deployment, while others require staging environments, deployment checks or human approval before production releases.

The appropriate approach depends on the application and its deployment requirements.

Is CI/CD a Good Skill for Junior Developers?

Understanding how software is tested, validated, built and delivered can strengthen your technical foundation.

However, simply listing “CI/CD” as a skill is weak if you cannot explain how a pipeline works.

A practical project that demonstrates your understanding gives you something more concrete to discuss in a portfolio or technical interview.

Ready to Build Your First CI/CD Project?

You now understand the basic structure of a CI/CD pipeline:

Trigger
   ↓
Validate
   ↓
Test
   ↓
Build
   ↓
Deploy

You also understand the role GitHub Actions can play in automating those stages.

The next step is to apply that knowledge.

Complete the CI/CD Pipeline Setup task to build a practical project you can document and use as evidence of your software development and DevOps skills.

Build the project. Understand the pipeline. Be able to explain every stage.