How To Set Up Your CI/CD With GitHub Actions

How To Set Up Your CI/CD With GitHub Actions

A CI/CD pipeline is essential for any project to develop and deliver software fast. It broadly falls under the DevOps branch of the project. A perfectly crafted CI/CD pipeline leads to better quality development, touching all aspects from feature addition, testing, delivery, etc.

CI → Continuous integration

CD →Continuous Delivery

CI is responsible for automatically building, testing, and integrating code changes with a shared repository.

CD is responsible for delivering code changes to stage or production environments for approval.

What is the point of a CI/CD pipeline?

The primary motive for setting up a CI/CD pipeline is to streamline and automate deployments.

It is a pipeline that automatically runs tests, builds code, and deploys code. It is like a hard block of tests and tasks that every push must endure before deployment.

Continuous testing(part of the CI/CD pipeline) ensures that your codebase remains stable and ready at any time.

Developers also commit smaller changes more often instead of one huge release.

CI/CD frees developers and organizations from manual, tedious tasks. This way, they can focus on innovation. They also get more time to understand their customers' needs and behavior using tools like google analytics and DevRev.

It reduces manual tasks for developers, thus reducing developer hours. Thanks to automation, the end product is always consistent. This makes debugging and other tasks easier to complete.

Due to this heavy reliance on automation, the pipeline has to be set up perfectly, following the software development cycle chosen.

4 Stages of a CI/CD pipeline

There are essentially four main stages that can further bifurcate into smaller tasks based on the requirement.

Acquiring Source

In this pipeline step, the latest source code enters the pipeline, which is triggered based on the configuration. You can configure this to trigger after every commit.

This is the first stage which further triggers the other stages sequentially.

Building

After the source is acquired, the next step involves building the code to make it into runnable software. Any failure in the builds indicates an error in the source code. All bundles and packages are made here, ready to be shipped to production.

Preliminary tests are run before the build process to ensure build minutes are not wasted.

Tests

After the building step, routine tests are run on the runnable instance to ensure no breaks in the code. Setting up an all-encompassing testing facility is good practice, as the software from here on out directly reaches the customer.

This is the last step before the code is deployed.

Deployment

Deployment is the final step in a CI/CD pipeline.

After finishing all the previous stages sequentially, the latest code is finally ready to be shipped out. Packages are then shipped to the designated environments, like staging, for further testing or production.

Using GitHub Actions for Deployment

Using the GitHub Actions tool is easy if you use Git as a version manager for your code.

Key Advantages

  • The CI/CD pipeline setup is simple: GitHub Actions is made by and for developers. You don't need dedicated resources to set up and maintain your pipeline. There's no need to configure and set up CI/CD manually.
  • Respond to any webhook on GitHub: Since GitHub Actions is fully integrated with GitHub, you can set any webhook as an event trigger for an automation or CI/CD pipeline. This includes pull requests, issues, and comments, but it also includes webhooks from any app you have integrated into your GitHub repository.
  • Community-powered, reusable workflows: You can share your workflows publicly with the wider GitHub community or access pre-built CI/CD workflows in the GitHub Marketplace. Support for any platform, language, and cloud: GitHub Actions is platform agnostic, language-agnostic, and cloud-agnostic. That means you can use it with whatever technology you choose.

Step-By-Step Guide For this example, we'll look at an Open-Source Scaffold-ETH project to show the operation. Step 1: Choose your project Select your git Project from your Repository/Company in which you want to set up your CI/CD pipeline, and move to the Actions tab.

Screenshot 2022-07-21 at 2.05.14 PM.png

Step 2: Choose the correct Preset and start writing your CI/CD workflow The CI/CD pipeline is written in YAML. YAML is a markup language that follows a JSON-type form. YAML is a markup language that has become a mainstay in declarative automation due to its human-friendly nature as a JSON superset (it uses fewer brackets, braces, and quotes than other JSON markup language variants).

Screenshot 2022-07-21 at 2.06.26 PM.png

Choose Docker image. This will build a Docker image to deploy to a registry.

Screenshot 2022-07-21 at 2.15.52 PM.png

Step 3: Start committing and trigger your pipeline After selecting your preset, you can start configuring it and customizing it to your liking. You can add tests, deploy to different environments, add Environment variables, etc.

The floor is ready to start building!

After finishing up, Start committing your changes, so you can watch your workflow start. This .yml configuration file will be available in the .github folder of your project.

Step 4: Monitor your Workflows You can view the progress status, the current task being run, and errors while the workflow is running on the GitHub page of your project.

You can use many tools to understand a workflow's status.

Screenshot 2022-07-21 at 2.19.10 PM.png

Here I'm using the visualizer tool to get the current status.

Build Logs and Live Logs are all available in the console.

Once completed successfully, You have completed your workflow, and CI/CD pipeline is set up.

A few Tips

Here is a small list of tips and tricks to ease your time building a CI/CD pipeline -

  • Never try to run jobs that change code during the workflow process.
  • Setting it up right the first time will take a lot of commits. Be patient.
  • Try to do preliminary setup tests before building to make sure you don't waste your precious build minutes (Linting jobs)
  • Setup different workflows for isolated tasks (e.g., Backend deployment vs. Frontend deployment)