CI/CD

/

Introduction

Developer

User

CI/CD

/

Introduction

CI/CD

/

Introduction

What is CI/CD?

Continuous Integration and Continuous Deployment

Software Works Everywhere
👺 Myth : I can test it myself!

CI/CD

/

Introduction

CI: Teamwork made easy
CD: Launch with confidence
Quick Feedback Loop
Security

Continuous Integration, or CI, is like a team huddle. Everyone brings their code—like a new filter for blog posts—and CI checks it works with the main app. It runs tests automatically to spot problems fast.

Continuous Deployment, or CD, takes your tested code and puts it live—like publishing your blog app for the world to see—without you lifting a finger. Continuous Delivery is similar but waits for your “go.” Both save time!

Why does it matter? You get feedback quickly! Did it break? Is it working as expected? Fewer bugs sneak in, and teamwork feels smooth. No more “it works on my machine” headaches! Also, it builds confidence! In our blog app, users see posts and filter by tags; admins add posts. CI/CD tests the filters and deploys new code seamlessly.

CI/CD also strengthens security in your app and implements crucial principles. We can picture it like a guard tower protecting our app.

Secure design principle builds security into our app from day one—like ensuring our admin login page isn’t easily hackable. You ensure that security-related tests are in your code base. If we skip this, the whole tower falls!

Next, we protect the app data. This means keeping secrets safe—like not exposing our admin password in the code. For our app, we’d hide API keys in environment variables so hackers can’t steal user data.

Then we have Operational Continuity. This ensures our CI/CD pipeline runs smoothly—like deploying new blog posts without downtime. If our pipeline breaks, users can’t see the latest content!

At the top is Trust Maintenance. It’s about keeping our pipeline trustworthy—like ensuring no one sneaks bad code into our app. For us, this means only trusted team members can approve deployments.

This hierarchy keeps our blog app safe at every step. Secure Design protects the admin panel, Data Protection hides user info, Operational Continuity keeps posts live, and Trust Maintenance ensures our CI/CD pipeline isn’t tampered with. Security is a team effort!

CI/CD

/

Infinity Loop

Here’s the CI/CD Infinity Loop—that shows the full lifecycle of your app.

The right loop is where the action starts. It’s a clockwise cycle: Plan is brainstorming—like deciding to add a ‘filter by tag’ feature. Code is writing it in TypeScript. Build is compiling it into something runnable, like bundling our Next.js app. Test is running automated checks—does the filter work? If not, we will fix it here before crossing over.

The left loop picks up after tests pass. It’s also clockwise: Release packages the app—like zipping it into a deployable file. Deploy sends it live to a server for users. Operate is the app running—users filtering posts. Monitor watches for crashes or slow performance, feeding info back to Plan via a dotted line, closing the loop!

For our app, we plan a tag filter, code it, build the NextJS app, and test it (CI). Once it’s solid, we release a package, deploy it to Vercel, operate the live site, and monitor user feedback (CD). The crossover ensures only good code goes live!

CI/CD

/

Github Actions

    # .github/workflows/ci.yml
name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install PNPM 📦
        uses: pnpm/action-setup@v4
        with:
          version: 10.4.1
      - name: Install Dependencies
        run: pnpm install
      - name: Run Tests
        run: pnpm test
      - name: Build Project
        run: pnpm run build

Let’s use GitHub Actions to set up Continuous Integration for our Next.js blogging app. It’s a robot that runs our tests and builds every time we push code—keeping our app reliable. We’ll break down each part of this workflow file!

The workflow file is a YAML file that must be stored in the dot github/workflows directory. In our case, we named it ci yml. YAML is a more concise version of XML.

We name this workflow CI Pipeline. You can have several pipelines in the same codebase and choosing a good name is beneficial. Our name ... sucks.

Then we need to define triggers, which specify when do we want to run our pipeline. You can run simple pipelines on every push, but deployment pipelines only when code is pushed to the main brach. In this case, push runs this when we update the main branch—like adding a new feature. The "pull_request" also runs it when we propose changes—keeping teamwork safe!

Then, we can define several jobs; in our case, we define a new job we named build-and-test. Think of jobs as chapters in the robot’s to-do list—one job can have many steps!

Next, we need to provide the container in which this pipeline runs. If you are not aware of containers, they are like virtual machines that you can run on your computer, with different operation systems. In this case, we chose the Linux system, Ubuntu, from the container ubuntu-latest—it becomes the computer the robot uses, a Linux machine provided by GitHub, fresh and fast!

Steps provide the step-by-step instructions. Each step is a mini-task—like fetching code or running tests—that builds up to a solid app!

The "uses" property provides the name of the action you wish to execute. In our case, actions/checkout step uses a pre-made action to fetch our blog app’s code from GitHub. It’s like downloading the latest version so the robot can start working!

You can also name your action, in this case we named it Setup NodeJS. We use actions/setup=node action to set up Node.js , which Next.js needs to run. The ‘with’ part customises it—think of it as telling the robot, “Use this tool kit!”. In our case, we tell the robot to use NodeJS version 18!

Next, we install our favourite package manager PNPM, and we specify to use version 10 4 1.

We can also run command in the target operating system, provided in the run parameter. This command installs all libraries that our blog app depends on. You do it locally, we need to do it in the container!

Then, we run another command to execute our tests.

If all steps are executed well, we will build our project. There could be some build or compilation errors. It's always good to build the app to ensure the CD pipeline does not crash! Pretty impressive, huh? It's like providing a robot with a recipe of things you would like to create!

CI/CD

/

Case Study

Scenario: Blog App Live
Delete Post Without CI/CD -> All Post Deleted
CI/CD Catches Bug
CI/CD Saves Time

CI/CD

/

Try It

Add a small change (or a bug)
Push it
Watch GitHub Actions catch it

    https://github.com/WesternSydneyUniversity/comp3036-ci-cd-introduction

CI/CD

/

Try It Locally! 🥸

Docker Desktop
ACT Tool
Docker Config Tweak
Run with act

or with act -j job-name

I’ve tinkered with GitHub Actions a ton. Pushing tiny changes to test them online can take forever—commit, push, wait, repeat. Good news: there’s a tool called ACT to run GitHub Actions locally, so you can experiment faster!

To run Github Actions locally you must install Docker Desktop—it’s like a mini virtual machine that runs the same environment GitHub Actions uses. Download it from docker.com and set it up!

Then, you need the ACT tool. Please use instructions on their website to install it on your computer. On mac its as simple as running brew install act.

Then we need to do one adjustment. In Docker Desktop, go to Settings General Virtual Machine Options. Switch the file-sharing implementation to gRPC FUSE. I had to do this to make ACT work smoothly—saves you the headache!

To run this, run act with j parameter build-and-test in your cloned repo folder or just run "act" to execute all pipelines. This simulates the “build-and-test” job from our CI pipeline locally. You’ll see it fetch code, install NodeJS, run tests—everything, right on your screen! Act tool allows you to tweak the pipeline—like adding linting—without spamming GitHub. It’s faster, and you’ll feel like a CI wizard!

CI/CD

/

Alternatives

Ease of Use : ✅ Github Actions

Cost: ✅ Github Actions

Flexibility: ✅ Jenkins

Community: ✅Github Actions

You have many other options when it comes to creating CI pipelines. Let's explore a few!

Jenkins is a popular CI tool that’s been around forever. It’s an open-source platform you install on your own server. For our blog app, Jenkins can run tests and builds just like GitHub Actions, but you’d set up a ‘pipeline’ in a Jenkinsfile—similar to our ci yml. It’s super customisable, so you can add plugins for everything, like Slack notifications when a build fails!

CircleCI is cloud-based, like GitHub Actions. It’s great for speed—think of it as a racecar for testing our blog app’s tag filters. It uses a config yml file and has a cool dashboard to watch builds.

Travis CI is another cloud option, often used for open-source projects. It’s simple to set up with a travis yml file, perfect for beginners testing our admin post feature.

GitLab CI/CD is built into GitLab, a GitHub alternative. It uses a gitlab-ci yml file and can deploy our blog app to a server—great if you’re already using GitLab!

If we compare how easy is to use Github Actions with alternatives, GitHub Actions wins here—it’s built right into GitHub, so you don’t need a separate setup. Jenkins requires installing on a server, which can be tricky for beginners working on our blog app.

GitHub Actions takes the prize for cost as it is free for public repos and has a generous free tier for private ones—perfect for students. Jenkins is free but needs a server (which might cost money). CircleCI and Travis CI have free tiers but charge for more usage.

Jenkins is the king of customization—you can make it do anything with plugins. GitHub Actions is flexible too, with reusable ‘actions,’ but Jenkins has more options for complex setups, like integrating with older systems.

GitHub Actions has a huge community because it’s part of GitHub—tons of pre-made actions for our blog app. Jenkins has a big community too, but it’s older, so some resources feel dated.

CI/CD

/

Wrap Up

CI/CD saves the day
GitHub Actions rocks
Automate early, test everything
Don’t skip tests

Full Stack Development

Continuous Integration (CI)

CI/CD

Introduction

CI/CD

Introduction

CI/CD

Introduction

CI/CD

Introduction

CI/CD

Infinity Loop

CI/CD

Github Actions

CI/CD

Case Study

CI/CD

Try It

CI/CD

Try It Locally! 🥸

CI/CD

Alternatives

CI/CD

Wrap Up