Build Automated CI/CD Workflows with Github Actions : Part-1

In this article series we will explore about Github Actions and see how you can automate, customize and execute your software development workflows with Github Actions.

Github Actions

This article i.e. Part-1 will focus on demystifying some of the terminologies like-

1. What is a CI/CD Pipeline?
2. What is Github Actions?
3. Basic Building blocks and components of Github Actions

So let’s get started with our CI/CD journey with Github Actions.

What is a CI/CD Pipeline?

CI and CD are two acronyms frequently used in modern development practices and DevOps. CI stands for Continuous Integration and CD stands for Continuous Delivery. This are the methods for automatic app development and deployment.

Continuous Integration

It is a DevOps best practice where code changes are automatically built, tested and merged with the existing code.

Continuous Delivery

It means after integrating the changes with the existing code, new app or versions of that app are published automatically.

For better understanding let’s look at the typical CI/CD Workflow in the diagram below-

CI/CD Workflow

Without the CI/CD Pipeline, each step in the diagram above will be performed manually by the developer. In essence, to build the source code, someone on your team has to manually run the command to initiate the build process. Same thing with running tests and deployment.

With the CI/CD Pipeline, we set up a mechanism that automatically starts the build process, runs the tests and deploys to production environment as an official release.

Nowadays there are many tools that help us automate tasks within your software development life cycle like Gitlab CI/CD, Azure Pipelines, AWS Pipelines, Jenkins etc. If you are familiar with Github, they also provides Github Actions and you don’t need to use third party tool for your CI/CD pipeline.

After this headstart, let’s now dive deep into Github Actions.

What is Github Actions?

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

Let us now look at the components of Github Actions and how do they work.

Components of Github Actions

Github actions get configured or triggered whenever some event occurs on a repository like pushing code, opening/closing of a pull request or an issue.

Github Actions Workflow

Let us understand with the help of this diagram-

Let’s say there is a github repository on which some people are working and any user who has the access to the repository can push, open a pull request or an issue and many other things.

The actions like push, creation of pull request etc. acts as a trigger to start the workflow in a github action. But what is a Workflow?

Workflow

Workflow is a collection of a single or multiple jobs that can be executed concurrently as well as sequentially.

Workflows get triggered upon an event like push, creation of pull request etc. This events actually define on what action on the repository the workflow will start executing. This workflow can either be triggered manually or automatically or at a defined schedule.

Jobs

A job is a set of steps that execute on the same runner. By default, a workflow with multiple jobs will run those jobs in parallel. You can also configure a workflow to run jobs sequentially.

Steps

A step is an individual task that can run commands in a job. A step can be either an action or a shell command. Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.

Let us now understand all the components in reference with the above diagram -

We have two cases where our jobs can run either parallelly or sequentially so let’s look at them separately.

Jobs running parallelly-

• We have a workflow named Workflow 1 in our repository. We want to run it whenever someone pushes the code onto the repository.
• Workflow 1has two jobs job1 , job2. Each job can have arbitrary number of steps which gets executed sequentially.
• So when a user pushes any code to our repo, job1 and job2 in Workflow 1 will run parallelly and workflow will be executed.
• If any step inside a job1fails, it will not impact job2 as the jobs are running parallelly, however Workflow 1 will still fail.

Jobs running sequentially-

• We have a workflow named Workflow 2in our repository. We want to run it whenever someone pushes the code onto the repository.
• Workflow 2has two jobs job1 , job2. Each job can have arbitrary number of steps which gets executed sequentially.
• So when a user pushes any code to our repo, job2 will be triggered only when job1 finishes successfully as jobs are now running sequentially.
• If any step inside a job1fails, the job2 will not get executed and so Workflow 2 will fail.

We can have more than one workflows and it must be stored in .github/workflows folder in the root directory of the source code.

Workflow files are written as YAML files.

I hope this understanding of the components with the help of a example would help you in learning the concept much better.

Let us now look at some of the more components of Github Actions-

Runners

A runner is a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. So runners are remote computers or Virtual Machines that GitHub Actions uses to execute the jobs you tell it to.

GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows. Each workflow run executes in a fresh, newly-provisioned virtual machine.

Actions

An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. For ex. you can consider installing NodeJS as an action. How?

Since there is a different runner for every job, so if in every job you need to install NodeJS in your runner that would be a repetitive step and it’s a complex one as you might want to work on different versions of NodeJS.

So we have the options of having this actions either from third party or make our own which can help us perform this repetitive task with simplicity.

That’s it for this article, where we learnt about CI/CD, Github Actions and its components. In the next part of the series we will be building our first workflow, setting up jobs and steps in our repository and all the practical stuff. So stay tuned for Part-2!!

Link to Part-2 where you will learn how to build our first workflow with a single job, multiple jobs running parallelly and sequentially and after that another workflow with a Issues event where we displayed the event details whenever a new issue was created.

If you enjoyed reading this article, please do leave a clap or a comment and you can also connect with me on LinkedIn and Twitter. You can follow me on Medium as I keep writing about new things that I learn and share that with you guys!!

Important Resources

1. Github Actions by Github
2. CI/CD by Redhat

New to trading? Try crypto trading bots or copy trading on best crypto exchanges

Join Coinmonks Telegram Channel and Youtube Channel get daily Crypto News

Also, Read

• Free Crypto Signals | Crypto Trading Bots
• An ultimate guide to Leveraged Token
• 16 Best Folding Electric Bikes
• 28 Best Electric Bikes Review
• Top 3 Binance Futures Trading Bots