Continuous integrations for VPS with GitHub actions

In this blog post, I will show you how Github Actions work and how you can use it to spend less time deploying and more time coding.

I will also walk you through a tutorial to set up your CI/CD pipeline and continuous integrations for VPS with GitHub actions workflow.

What is continuous integration?

Continuous integration or Continuous Deployment pipeline or CI/CD pipeline for short is a set of automated processes that picks up the code from version control and will automatically run a sequence of actions like testing, building, and deploying the application.

What is Github Actions?

It is one of the features that Github provides. It relies on the GitHub webhooks API to detect commits and pull requests and allows you to build and deploy your code and set up your continuous integration workflow.

You're able to create pipelines with customizable actions per stage, monitor your repository for changes, and run the appropriate pipeline for the event that triggered. For example, if some new changes are added to the main branch, then build the project, run some tests, and automatically deploy the application.

You can specify conditions that need to be fulfilled before running actions, you can also create your custom scripts or use ready-to-use workflow templates.

What are the Advantages of GitHub Actions?

No more Re-deploying

Deploying your application once you make changes to your code manually could be exhausting, and repetitive.

On a personal use case, let's say you deploy your apps manually. You write some code; you push it to GitHub, ssh into your VPS, pull the changes from Github, build and deploy, and forget to add something? REPEAT. Exhausting right?

Using actions, you can create your own continuous integration pipeline that does all of those actions for you completely automated, what you have to do is push it to GitHub, and GitHub will take care of your workflow.

Continuous deployment for open-source projects

Open source projects take outstanding advantage of continuous delivery or continuous integration; it makes everything much more straightforward.

Imagine maintaining an extensive open source project, and contributors send pull requests all the time, some of those pull requests might break your code if you merge it into your main branch.

What can you do? You can set up a workflow with Github Actions and build and test the app every time someone creates a pull request so that before you even try to consider reading a pull request, you already see that this pull request breaks some part of your code.

No third-party tool

The best thing about GitHub Actions is that you probably already use GitHub.

So it's much better to let GitHub handle the continuous deployment workflows for you rather than using some other third-party tool to manage your CI/CD pipeline and build high-performing, secure pipelines.

A large variety of already set up workflows

You don't need to manage your workflows; you can use already made environments to set up your continuous delivery workflows.

It is easy

Github CI/CD pipeline is also more accessible than other CI/CD tools and does not require you to have a full-time DevOps team that is cost-intensive and not ideal for startups. Instead, you can quickly learn how to use it and create workflows with your development team.

You don't need a server to run actions

All these actions will be happening on Github servers. This means you save resources because you don't have to run them on your server.

How does it work?

These Actions that we talked about will only trigger when specific events happen, like push and pull request. Let's say that we only want a particular action to happen only when the event is push, meaning that every time some new changes are being pushed to the Github repository.

So basically, GitHub will listen to an event and trigger the actions given by the developer.

Each job will run on a different server, for example, any job in the job tag is run by a server, and another job has another server.

Sometimes we want jobs to run one after another. If we decide to do so, we need to use the needs tag in the other job and include the other jobs` name. More of this later

The CI/CD pipeline

Today, one of the most common workflows is the CI/CD pipeline, which runs some actions in order.

• Commit: you commit your changes to GitHub.
• Test: Workflow starts running tests.
• Build: Build starts if the test ran successfully.
• Deploy: Deploys the latest changes to the server.

Code is pushed from development to a testing environment and finally to production for end-users to access.

The Github workflow file

Github Actions is a workflow file that is a .yml file to define workflows. So if you don't have a basic understanding of reading YML, I recommend reading some articles about it.

There are many syntaxes that Github uses to define workflows, I will talk about the most used and common ones, and later in this article, we will write our workflow for a node.js application, test it and then deploy it to our own VPS

An example of the GitHub actions workflow file.

Here are some of the most important .yml syntaxes of Github workflow:

• name: is the name of your workflow file.
• on: contains the list of events in which we want to trigger the action.
• jobs: The list of jobs we want to run after the event happens.
• runs-on: is the operating system in which you want to run the workflow.
• steps: a list of actions you want to run after the event happens.
• uses: you can import other people's written actions and re-use them.
• with: a list of variables. Think of it as environment variables.

GitHub secrets

Sometimes you want to add a password or a private key inside your workflow file, but you don't want other people to see it, and you still want to run the actions.

In this case, you can put your repository secrets from your repository settings; you can specify the name of your key and the value of your key just like environment variables.

Later you can use these secrets in your .yml file by using the ${{ secrets.YOUR_SECRET }} syntax.

Writing a sample Github workflow

In this tutorial, I'll show you how to set up a GitHub workflow so that when we push some changes to our main branch on GitHub, our website will automatically build, test, and host itself again. which will save us a lot of time & effort.

So, in summary:

• We push some changes to Github.
• Event triggers.
• Github will download our code and test it on their server.
• If the test is successful, Github will access our VPS using SSH keys.
• Fetches the latest changes.
• Builds the app.
• Restarts the app.

The following code shows the Github workflow file for testing, building, and hosting a node.js app on a Virtual private server using SSH keys:

name: Node.js CI

on:
  push:
    branches: [master]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"
      - run: npm i
      - run: npm run build
      - run: npm run test

  deploy:
    needs: build-and-test
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.IP }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.KEY }}
          script: |
            cd path/to/your/app/directory
            git checkout .
            git pull
            npm run build
            pm2 restart MyApp

The first job we have created is to build and test the app on the Github servers.

If the first action is successful, the second one will be executed. We specified this by using needs syntax and adding the previous job name.

Great, now your server hosts itself again without you having to worry about build fails or errors in your code. Now, you can spend more time coding and less time re-deploying.

Thank you for taking the time to read the blog post, I hope this blog helps you in building the best software development life cycle for your projects. If you found it helpful, consider sharing it to let other developers know about GitHub actions.