Week 13 - Systems

App Development lifecycle

Continuous integration (CI)

Continuous Delivery (CD)

Packaging and Docker

Docker setup

Building an API server

Deployments

Intro to Cloud

Using local LLMs

Appendix 1 yaml syntax

Appendix 2 Docker commands

Practice

Assignment

Core program

Under construction

Continuous Integration (CI) is the practice of automatically building and testing code every time a developer pushes changes to a shared repository.

The idea is straightforward: instead of developers working in isolation for weeks and then merging everything together at the end (which usually results in painful conflicts and broken code), they integrate their changes frequently - often multiple times a day. Each integration triggers an automated process that builds the code, runs tests, runs additional checks and reports whether anything is broken.

These days, many development teams have a CI pipeline set up in order to catch problems early, keep the codebase stable, and potentially speed up the whole development process.

Watch: what is CI?

https://www.youtube.com/watch?v=1er2cjUq1UI

How CI helps developers

  1. Catches broken code early - if something fails → you know within minutes, not days
  2. Protects the main branch - PRs can't merge until checks pass, so main stays stable
  3. Removes "works on my machine" - CI runs in a clean environment (like a fresh machine), so if it passes there, it's reliable.
  4. Gives confidence to change code - refactoring is less scary when you know tests will catch issues.

Example CI pipeline

  1. Developer pushes code
  2. The CI server detects the change and pulls the latest code and performs actions
  3. Installs all dependencies (e.g: npm install)
  4. Builds or Compiles the application
  5. Runs unit tests
  6. Runs the application with test data
  7. Reports the results (pass / fail) to a Slack channel

Each team will have its own pipeline tailored to its needs and technologies. Some pipelines are simple and run in seconds, while others can take many minutes to test everything thoroughly.

CI with GitHub Actions

image.png

GitHub actions provides a free and easy to use CI/CD platform. Makes it easy to automate all your software workflows, interact with GitHub pull requests and a lot more.

Watch: Overview of GitHub actions in less than a minute

https://www.youtube.com/watch?v=URmeTqglS58

A Simple Hello workflow

In the following example we created a simple workflow that prints “Hello World!” on every push to main.

name: Hello World

# Here we specify the events that trigger the workflow.
## In this case, there are two triggers: 'push' and 'workflow_dispatch'
on:
  push:
    branches: [main] # Trigger the workflow on push to the main branch
  workflow_dispatch: # Allow manual triggering of the workflow from the GitHub Actions tab

# Here we define the jobs that will run as part of this workflow.
jobs:
  # This job is named 'hello' with a single step
  hello:
    runs-on: ubuntu-latest
    steps:
      - name: Say hello
        run: echo "Hello World!"

<aside> 💭

GitHub Actions workflow files use the YAML format. YAML is a common format for modern configuration files. It is easy to read and learn. For more information, check out Appendix 1 yaml syntax.

</aside>

Watch: creating a sample workflow

https://youtu.be/eCOv4AeC6Ic?si=1DsBLy2zZ8-35AT0&t=52

All GitHub actions workflows must be places in a special folder in your repository:

.github/workflows

<aside> ⌨️

Hands on:

  1. Create a new GitHub repository.
  2. Create the workflow path: .github/workflows
  3. Add the sample hello workflow and save it in: .github/workflows/hello.yaml
  4. Commit and push the code </aside>

Running a workflow

If a workflow runs on push, your commit will get either a green checkmark if the CI job passed or a red cross if it failed.

A commit with a green checkmark indicating that all CI jobs were successful.

A commit with a green checkmark indicating that all CI jobs were successful.

Viewing your workflows on GitHub

In the GitHub repository, go to the Actions tab to see an overview of all workflows and their status. You can also re-run or manually trigger new workflow runs.

image.png

You can also check the logs for a specific workflow run. Here is an example from run #1 of the hello workflow above.

image.png

<aside> 💡

Most workflows run on Linux machines because they are cheaper and faster. However, it is possible to run jobs on a macOS or windows.

</aside>

A more practical workflow

The previous example was easy but quite useless. In the next example, we will create a simple CI pipeline for a Node.JS project that runs unit tests. Here are the steps:

  1. Check out the latest code
  2. Setup a clean Node.JS environment
  3. Install all dependencies with npm install
  4. Run tests with vitest

And here it how ti looks like

name: Integration

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

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

      - name: Set up Node.js
        uses: actions/setup-node@v6
        with:
          node-version: "24" # Can also use 'latest'

      - name: Install dependencies
        run: npm ci          # npm clean install

      - name: Run Unit Tests
        run: npm test        # Run vitest tests (defined in package.json

The workflow above has one job with multiple steps. Note that there is a new trigger called pull_request - this means that the workflow will run when we create a new PR to be merged to main branch.

<aside> 🎉

This workflow ensures that all unit tests pass on every push to main and when creating a pull request.

</aside>

Key takeaways

Imagine you are not alone anymore to work on your project and you want everyone to have the same code styling to ensure your code base remain easy to maintain and read from everyone.

Using Pull Request with automation such as the one we just did will make sure any code that is added to the main branch passed all the same exact steps and tests.

This is what we call the Integration part, literally, it means integrating new code into the code base, ensuring the new code follows the same rules than the rest of the code base.

Different projects run different checks as part of their integration steps, but in general you'll find these three main ones:

Additional Resources

Reading

Video

The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*

CC BY-NC-SA 4.0 Icons

Built with ❤️ by the HackYourFuture community · Thank you, contributors

Found a mistake or have a suggestion? Let us know in the feedback form.