Magic of Github Actions: The super-awesome CI/CD

A Very Simple Example

Instead of explaining to you theoretically, I’d prefer to start with a simple example to help you learn better.

I’d begin with an example of a React App.
* In case you are not familiar with ReactJs then also it doesn’t make much of a difference as you‘d easily be able to understand.*

Generally, for any app, after writing the code, we have to build it(into production) and then deploy it. The command varies from framework to framework. For ReactJs the command is npm run build . This command would generate the build files in a folder name build .
The next step would be to deploy this to surge or any such hosting platform.
To deploy to surge we simple use this command:
surge ./build myfreedomain.surge.sh --token my_private_surge_token

Okay, so this is what you’d do when you are developing and executing all commands on your local system. What if there’s a very easy way that you simply push your code on Github and it gets automatically built and deployed to Surge. Well, that’s very very easy with Github Actions.

Configuring Auto build and Deployment with Github Actions

We can start by creating a simple config file(in ./github/workflows`) and that’s it !!
Looks at this file my-ci-cd.yml :

name: my-ci-cd

on:
  push:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Setup Node
      uses: actions/setup-node@v2-beta
      with:
          node-version: 12

    - name: Build React App
      run: |
        npm install # Install Dependencies
        CI=false npm run build # CI=false to ignore warnings

    - name: Install Surge
      run: npm install -g surge

    - name: Deploy to Surge
      run:  surge ./build ${{secrets.SURGE_DOMAIN}} --token ${{secrets.SURGE_TOKEN}}

Explanation:

• name: Well that’s your choice to use any suitable name for the file
• on: This part defines the events on which this file will be triggered. For example, here we are triggering the workflow whenever we push to the master branch. We could also trigger workflow on other events like a Pull Request or Releases.
• jobs: The Parent wrapper for a set of jobs that this workflow will carry on. For example, here we have only one job named buiild in which we are doing both the processes.
• runs-on : Here we specify the Operating system on which we want to execute our workflow. We can use ubuntu, macos and windows .
• steps : Every job can be broken down into smaller sub-jobs or steps.
• name : The name of the step
• run : The command to execute.

If you’d see the file above it's very simple to achieve CI/CD with Github Actions. You don’t need to do much and yet you get so powerful!!
You can see this as a part of the project on this repo https://github.com/helloworld-iiitt/iiitt.

Summarizing Github Actions

GitHub Actions is an API for GitHub cause and effect: coordinate any workflow, based on any case, while the execution is handled by GitHub, provides rich feedback, and secures every move along the way. Workflows and steps are only a piece of code in a repository with GitHub Actions, so you can build, upload, reuse, and fork your methods of software development.

It’s simpler to automate how you build, test, and deploy your projects on any platform, like Linux, macOS, and Windows, with GitHub Actions. In a container or in a virtual machine, run your workflows. More languages and frameworks are now supported than ever by Actions, including Node.js, Python, Java, PHP, Ruby, C / C++, .NET, Android, and iOS. Testing multi-container apps? You can now test your web service and its database together by simply adding some docker-compose to your workflow file.