CI, or Continuous Integration, is a development practice where developers integrate code into a shared repository frequently. This usually happens multiple times a day and is complemented by automated tests.

CD, or Continuous Deployment/Delivery, takes the code changes from a repository, automatically builds and tests them, and then automatically deploys the tested code to a live service.

These practices make it easier to catch bugs earlier and make deployments faster and more reliable.

What are GitHub Actions?

GitHub Actions is an automation framework that runs in your GitHub repository. It can build, test, and deploy your code right from GitHub.

Key Components

1. Workflows: Orchestrates your CI/CD process.
2. Jobs: Sets of steps that execute sequentially.
3. Steps: Individual tasks within a job.
4. Actions: Pre-built steps that you can use in your jobs.

Setting up a Simple Workflow

To set up a simple GitHub Actions workflow, navigate to your GitHub repository and then to the Actions tab. From there, you can create a new workflow.

Here’s a basic example:

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

This YAML file specifies a single job called build that runs on an ubuntu-latest runner machine. The job has a single step that uses actions/checkout@v3 to download the code from the GitHub repository.

For more information on Github Actions Syntax refer to their documentation: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

Testing is crucial in CI/CD pipelines. GitHub Actions can automatically run your tests every time someone pushes to your repository.

For example, if you’re using Node.js and Jest for your tests:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install Dependencies
        run: npm install
      - name: Run tests
        run: npm test

Once your code has been built and tested, you can deploy it automatically using GitHub Actions.

Here’s a simplified example:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: npm deploy

In this example, we use a custom command script for deploy. In your package.json you will have a section for scripts:

  "scripts": {
    "deploy": "echo this is a deploy",
  }

In a real-world scenario, you often need multiple jobs to run different tasks in parallel or sequentially to speed up the process or manage dependencies. In this section, you’ll learn how to set up a workflow with multiple jobs.

Example: npm test and Deployment

Here’s an example YAML configuration file for a GitHub Actions workflow that has two jobs: one for running tests and another for deployment.

name: CI/CD Pipeline

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install Dependencies
        run: npm install
      - name: Run tests
        run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Deploy
        run: npm deploy

Understanding the Workflow

1. jobs: Contains two job blocks: test and deploy.
2. runs-on: Specifies the type of runner that the job will run on.
3. steps: The sequence of tasks that will be executed in each job.
4. needs: This key in the deploy job specifies that it needs the test job to complete successfully before it starts.

By defining both jobs in the same YAML file, GitHub Actions will know to run them as part of the same workflow. The needs keyword ensures that the deploy job will only run if the test job completes successfully. We add a layer of protection against bugs making their way into production.

And that’s how you set up a GitHub Actions workflow with multiple jobs. This allows you to make your CI/CD process more robust and maintainable.

In any development workflow, especially one that involves deployments, it’s common to have configuration settings that should not be hard-coded in the codebase. This includes API keys, database URLs, and other sensitive information. GitHub Actions allows the use of environment variables and secrets to manage these configurations securely.

Github Environment Variables

Environment variables are key-value pairs that you can create and modify as part of your workflow. They can be accessed in your GitHub Actions YAML file via env context. For example, to set a Node.js environment, you can do:

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production

And then use it in a script like this:

- name: Using Environment Variable
  run: echo Node environment is ${{ env.NODE_ENV }}

Secrets are similar to environment variables. The difference is that secrets are encrypted and only exposed to selected actions, adding an extra layer of security. Use secrets for storing sensitive data like passwords and API keys.

You can add secrets via GitHub by navigating to your repository, then clicking on Settings -> Secrets -> New Repository Secret. Enter the secret’s name and value, and it will be encrypted and stored securely.

To use a secret, use the secrets context in your YAML file like this:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Accessing secret
        run: echo Accessing secret ${{ secrets.MY_SECRET }}

Replace MY_SECRET with your actual secret’s name, stored in the GitHub repository.

For more information about environment variable refer to their documentation: https://docs.github.com/en/actions/learn-github-actions/variables and for information about secrets refer to: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions

In software development, we break down complex projects into smaller, manageable parts, which we work on for a week or two. These periods are called “sprints.”

A sprint backlog is like a to-do list. It lists what the team has decided to work on this sprint. It’s chosen from a larger list, usually called the “product backlog,” which holds the entire project to-do list.

For your course, the mandatory work has been scheduled already. You will add any other tickets you want to work on to your backlog and schedule them according to your own goals and capacity. Use your planning board to do this.

You will find your backlog in the Backlog view on every sprint.

Copy the tickets you are working on to your own backlog. Organise your tickets on your board and move them to the right column as you work through them. It’s a flowchart:

flowchart LR
    Backlog --> Ready
    Ready --> in_progress
    in_progress[In Progress] --> in_review
    in_review[In Review] --> Done