Level Up Your Projects with GitHub Actions & CI/CD

Introduction

In today's rapidly-evolving landscape of software development, streamlining workflows, fostering collaboration and producing reliable software have become indispensable goals for developers. Consequently, there has been a notable surge in the adoption of Continuous Integration/Continuous Deployment (CI/CD) practices across the industry.

GitHub, as one of the leading web-based Git repository hosting service, provides a powerful suite of CI/CD tools in the form of GitHub Actions. These are directly integrated into the platform which empowers developers to increase the speed, efficiency and reliability of delivering products. In this brief article, we will take a look at what CI/CD is, why we should use it, as well as some of its applications in my projects.

What is CI/CD?

But first, what is CI/CD? CI/CD, as you may have glimpsed earlier, is an acronym for Continuous Integration/Continuous Deployment, which encompasses a set of practices and methodologies aimed at automating various stages of the software development lifecycle. Specifically in GitHub, CI/CD is also often referred to as GitHub Actions. GitHub Actions can be used to automate tasks ranging from basic code linting and testing for correctness, to even simplifying and speeding up the deployment process.

Why use CI/CD?

Some of you might be thinking: "But I can lint, test and deploy all without CI/CD!" Now, while it's certainly true that all these tasks can be performed manually, leveraging on CI/CD brings about several advantages that can significantly enhance a developer's experience:

• Automation: A key benefit of CI/CD is automation. By automating repetitive tasks such as linting and testing, developers can free up their mind to focus on more critical aspects of their development work.
• Reliability: Running checks in your CI/CD allow you to catch bugs early, and acts as a safeguard in scenarios where individual developers may have neglected to test their changes. The catching of potential problems before they escalate leads to more reliable software and fewer surprises in production.
• Efficiency: With CI/CD, developers are able to quickly validate and receive feedback on their changes, leading to faster iterations and shorter development cycles. Having a streamlined development workflow also boasts better collaboration, enabling teams to deliver updates to production more rapidly and with greater confidence.
• Consistency: If you have developed in a team, then you may be familiar with the phrase: "But it works on my computer!" If you've been in those shoes, then the benefits of having CI/CD is obvious. With workflows managed on the Repository, all tests are run in a standardized environment which makes issues more easily reproducible.

Thus, despite it being possible to perform the above tasks manually, the benefits of CI/CD are manifold and adopting it can significantly improve the development process and the quality of the software produced.

Real-World Applications

Now that we've got a better idea of what CI/CD entails and the advantages that it offers, let's delve into a couple of real-world scenarios! Below, I share three examples drawn from my projects to illustrate how CI/CD, specifically GitHub Actions, helps enhance my development experience.

QuickTax

QuickTax originated as a Minecraft plugin designed to keep checks on economies in Minecraft servers. Initially developed for personal use, I eventually released it as an open-source project and the plugin found itself actively used by dozens of servers. With an active user base, maintaining the integrity of the plugin was important. At the bare minimum, changes shouldn't cause the build process to fail.

To provide myself with that reassurance, I added a simple workflow to GitHub Actions which I share below:

name: Build

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven
    - name: Build with Maven
      run: mvn -B package --file pom.xml

In the snippet above, we can see that the job is set to run whenever there are pushes or pull requests being made to the master branch. Within the job itself, it is simply checking that the plugin can be successfully built with Maven and Java 17. By automating this process, I am able to have the confidence that passing GitHub Actions imply my project can be built reliably.

React ChatBotify

React ChatBotify is a React library that allows users to effortlessly integrate a highly customizable chatbot to their websites. Available on npm, it is slowly gaining adoption and there is an increasing need to ensure its reliability and consistency for users. While the previous project had a single build workflow, this project contains 3 separate workflows for lint, test and build.

We won't delve into the details of the workflow files, as they are quite lengthy, but you can explore them on the project repository. In summary, the lint stage checks for code quality, while the build and test stage ensures correctness. Thus, when GitHub Actions succeed, I have the assurance that the quality of the codebase is upheld and that the library functions as intended.

Simple Media Converter

Simple Media Converter is a Telegram bot created for easy media conversions in my university days when lessons and submissions were mostly online due to covid. Initially, the bot was deployed via Screen and I had to do manual deployments after every code change. When I moved to Docker, I automated the entire deployment flow with GitHub Actions to simplify this process. You can find the workflow files on the project repository.

Recently, HealthPing was also added to notify me to ensure the application liveness. The end result? Pushing code changes to my repository automatically re-deploys my Telegram bot. Should there be errors with the bot, I am notified by HealthPing and I can simply run the deployment workflow again to re-deploy the bot. In fact, I could potentially take things further by having a failed HealthPing automatically trigger a redeployment - but that's a consideration for another time.

Conclusion

To wrap things up, we have seen what CI/CD is along with the benefits it can bring to your software development experience. I hope the examples provided above have convinced you of its usefulness in real-world applications.

If you are keen to look into how to automate an entire deployment process with GitHub Actions, look out for the upcoming article that will be covering how to automate Telegram Bot Deployment with GitHub Actions and Docker. Over there, we will dive deeper into the workflow files that we have skipped over in this article. As usual, if you have suggestions or feedback, feel free to leave them in the comments or reach out here. Thank you for reading, and I'll see you in the next article!