Continuous Integration and Continuous Delivery
Tags: devops, cicd
Published: 2022-06-14 14:09:51

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"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_
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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).

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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 

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.

![DevOps](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s9be5gt8dgqr5d0uvxc7.png)

#####_GitHub Actions_
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.

![github-action-1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f9tgojh3dfa8swlejz95.png)
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](https://docs.github.com/en/actions/quickstart). 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 😎

![gh-action-2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1km2a99cxc4j1h4te2o0.png)
We can see the process in action

![gh-action-3](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/edsvwh1vzebd82zl0e5l.png)
And when it's done we can successfully merge our changes..

![gh-action-4](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ms086y88xn3gqtnd4kq8.png)
Then delete our branch...

![gh-action-5](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/awdojov2eq2hqo7inypk.png)

And that is all there is to getting started with GitHub Actions. See how easy it was? I hope this helps you include CI/CD in your next project.