Continuous Integration (CI)#

No matter which of the deployment plans you choose, you will need a build pipeline. There are many third-party tools out there such asJenkins, Travis CI, andCircle CI, but to keep it simple, I will be using the vanilla GitLab and GitHub pipelines.

GitHub#

As most of you probably have a GitHub account, I will be starting with this one.

The GitHub CI is activated for your repository when you have a/.github/workflows folder with a YAML workflow file. This file can be called pretty much whatever you want, and you can have as many workflow files as you want. See more information about the configurationhere if you are interested. When you make any file changes to your repository on GitHub (push, merge, pr etc.), GitHub will check your .github/workflows folder and each of the jobs to see if any of them can be executed. There is currently no way to trigger the jobs manually, but you can rerun past jobs if needed.

Let's start by creating our YAML file: /.github/workflows/ci.yml, and adding the following to it:

name: CI

env:

  DENO_VERSION: 1.26.0

on:

  push:

    branches:

      - main

jobs:

  lint-and-format-check:

    runs-on: ubuntu-latest

    steps:

      - name: Clone repo

        uses: actions/checkout@v3

      - name: Install deno

        uses: denoland/setup-deno@v1

        with:

          deno-version: ${{env.DENO_VERSION}}

      - name: Deno formatting

        run: deno fmt --check

      - name: Deno linting

        run: deno lint

We've named our pipeline CI, then set an environment variable for our Deno version. We also want to only run the deployment for the main branch, but we want to allow it for all pushes. This is of course dependent on your requirements, but for this tutorial, it will serve as a good start.