Continuous Integration and Continuous Delivery

#devops #cicd

"What is Continuous Integration and why is it important?" If you are novice programmer, you may be asking yourself these same questions. CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment) used in DevOps (Software Development and IT Operations). CI/CD is a best practice where developers can frequently deploy code to production, without having to wait for manual approval, or worse waste a ton of time testing code manually. It allows developers to spend more time writing code and less time testing locally and manually deploying.

The Pipeline

If a developer is working on a feature and they want to make sure it is working correctly before they deploy it, without CI, they might have to run a series of tests locally or have print statements (console.logs) littered throughout their code base to ensure it's working. This process can take a lot of time and can be a lot of work. With CI, a developer can run a single command to check that the application is working correctly. This way the developer can spend more time writing code and less time testing. When merging or submitting a Pull request, the CI server will run the tests and if they pass, the code would be allowed to be merged into the master branch (or another branch).

Continuous delivery extends the idea of continuous integration to also include the process of deploying code and updating the live environment (or a staging area) after the build/testing stage. In addition to automated testing, you have an automated process that can deploy code with the click of a button. This can improve the deployment process so that develops can deploy code in small batches and test of debug more efficiently

Continuous deployment takes the process one step further, allowing every change that passes all the previous stages of the pipeline to be released to the live environment. Only a failed test would prevent the change to be deployed.

GitHub Actions

There are several different CI tools available to pick from. Popular ones include Jenkins, Travis, Gitlab and others. I will not go into too much detail about them, but they all have their pros and cons. Being that prefer to do as much as possible with the tools I use, I prefer GitHub Actions. It is easy to setup, and it is right in the browser.

Let us do a quick demonstration of how easy it is to set up GitHub Actions …
Open the terminal and cd into your repository’s root folder, then create a .yml file touch .github/workflows/action-demo.yml. In the .yml file we're going to paste some boilerplate code we got from the GitHub Actions Documentation. We will also add a couple lines at the bottom to install our dependencies and run our tests.

name: GitHub Actions Demo
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
      - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
      - name: Check out repository code
        uses: actions/checkout@v3
      - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}
      - run: echo "🍏 This job's status is ${{ job.status }}."
      - run: npm i
      - run: npm test

After we've written our code (in this case a simple arithmetic
function) and run our code locally, we're ready to push our code and open a pull request. from the terminal git push --set-upstream origin test (we are on the test branch). At GitHub we see an indication our code was pushed up and GitHub suggests a PR. How convenient 😎

We can see the process in action