Understanding GitHub Actions: A Powerful Tool for Streamlining Software Workflows

Introduction

GitHub Actions is a powerful automation tool offered by GitHub, designed to streamline software development workflows. With GitHub Actions, developers can automate various tasks, create custom workflows, and enhance collaboration, ultimately boosting productivity and efficiency. In this article, we will explore what GitHub Actions is used for, compare it to Jenkins, differentiate it from regular apps, and discuss two types of GitHub Actions.

What is GitHub Actions used for?

GitHub Actions is primarily used for automating various tasks related to software development and deployment. It enables developers to define custom workflows using YAML files, known as "workflow files." These workflows consist of one or more jobs, each containing a set of steps that execute actions. An action is a reusable unit of code that performs specific tasks.

Common use cases of GitHub Actions include:

• Continuous Integration (CI): Automatically building, testing, and validating code changes whenever new commits are pushed to the repository.
• Continuous Deployment (CD): Automating the deployment process to staging or production environments after successful CI.
• Code Quality Checks: Running linters, code formatters, and static code analysis tools to maintain code quality standards.
• Issue and Pull Request Management: Automating labeling, notifications, and issue closing based on specific conditions.
• Release Automation: Automatically creating and publishing releases, changelogs, and artifacts.

GitHub Actions vs. Jenkins:

Jenkins is another popular automation tool widely used in the software development industry. While both GitHub Actions and Jenkins serve the purpose of automating tasks, they differ in various aspects:

• Integration: GitHub Actions is tightly integrated with GitHub, making it easy to set up and use within GitHub repositories. On the other hand, Jenkins is a standalone automation server that requires additional configuration to work with GitHub.
• Syntax and Configuration: GitHub Actions uses YAML-based configuration for defining workflows, which is easier to read and maintain compared to the traditional Jenkins XML configuration.
• Scalability and Maintenance: GitHub Actions is a cloud-native service, which means it scales automatically based on demand and requires less maintenance effort. Jenkins, being a self-hosted solution, requires manual scaling and maintenance of servers.
• Community and Ecosystem: GitHub Actions benefits from the vast GitHub community, offering a wide range of pre-built actions readily available for reuse. While Jenkins also has an active community, GitHub Actions' ecosystem is more extensive due to its integration with the GitHub platform. For eg you can say using iPhone, Macbook and iPad.

Creating and Understanding your first workflow

name: CI Workflow


on:
  push:
    branches:
      - main


jobs:
  build:
    runs-on: ubuntu-latest


    steps:
      - name: Checkout code
        uses: actions/checkout@v2


      - name: Setup .NET SDK
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '5.x'


      - name: Restore dependencies
        run: dotnet restore


      - name: Build
        run: dotnet build --configuration Release


      - name: Run tests
        run: dotnet test --no-restore --verbosity normal
        

Explanation:

1. name: CI Workflow: This line sets the name of the workflow, which is "CI Workflow" in this case. It's useful for identifying the workflow in the GitHub Actions UI.
2. on: This section defines the event that triggers the workflow. In this case, the workflow will be triggered on every push to the "main" branch.
3. jobs: A job is a set of steps that execute on the same runner. In this workflow, there is only one job named "build."
4. runs-on: ubuntu-latest: This line specifies the operating system on which the job will run. Here, the job runs on the latest version of Ubuntu.
5. steps: This section contains a list of steps that will be executed as part of the job.
6. actions/checkout@v2: This step checks out the code from the repository so that subsequent steps can access the project files.
7. actions/setup-dotnet@v1: This step sets up the .NET SDK on the runner. The version '5.x' is specified, but you can change it to match the version required for your .NET project.
8. dotnet restore: This step restores the NuGet dependencies required for the project. It ensures that all necessary packages are available for building and testing the project.
9. dotnet build --configuration Release: This step builds the .NET project in "Release" configuration. It compiles the source code and generates the output files.
10. dotnet test --no-restore --verbosity normal: This step runs the unit tests in the project. The --no-restore flag is used to skip redundant restores, and the --verbosity normal flag sets the level of detail in the test output.

With this workflow, whenever a new commit is pushed to the "main" branch, GitHub Actions will automatically trigger the CI Workflow. The workflow will then checkout the code, set up the .NET SDK, restore dependencies, build the project, and finally, run the tests. If any of these steps fail, the workflow will be marked as unsuccessful, alerting the team to investigate and fix any issues.

By leveraging GitHub Actions for CI/CD, development teams can automate their build and test processes, ensuring faster and more reliable software delivery. Additionally, GitHub Actions provides a simple and easy-to-configure YAML syntax, making it accessible to developers of all levels of expertise.

We can also write a workflow for deployment. Below is the workflow which will deploy ASP.NET application in Azure Web App

name: CD Workflow


on:
? push:
? ? branches:
? ? ? - main


jobs:
? deploy:
? ? runs-on: ubuntu-latest


? ? steps:
? ? ? - name: Checkout code
? ? ? ? uses: actions/checkout@v2


? ? ? - name: Setup .NET SDK
? ? ? ? uses: actions/setup-dotnet@v1
? ? ? ? with:
? ? ? ? ? dotnet-version: '5.x'


? ? ? - name: Restore dependencies
? ? ? ? run: dotnet restore


? ? ? - name: Publish
? ? ? ? run: dotnet publish --configuration Release --output ./publish


? ? ? - name: Deploy to Azure Web App
? ? ? ? uses: azure/webapps-deploy@v2
? ? ? ? with:
? ? ? ? ? app-name: your-webapp-name? # Replace with your Azure Web App name
? ? ? ? ? package: ./publish        

Explanation:

This workflow is named "CD Workflow" and will also be triggered on every push to the "main" branch. It contains a single job called "deploy" responsible for deploying the ASP.NET web application to an Azure Web App. The steps within the job are similar to the CI workflow, with the addition of a step to publish the application using dotnet publish. The published output is then deployed to the specified Azure Web App using the azure/webapps-deploy@v2 action.

With these separate workflows, you can have independent CI and CD processes. The CI workflow will ensure that your ASP.NET web application is built and tested with each push to the "main" branch, while the CD workflow will deploy the application to the specified Azure Web App after successful CI execution. This modular approach makes it easier to manage and maintain each aspect of the development and deployment pipeline.

Conclusion:

GitHub Actions is a versatile tool that empowers developers to automate various tasks and streamline their software development workflows. Its integration with GitHub and extensive ecosystem of actions make it a preferred choice for many development teams. By understanding the key differences between GitHub Actions and other tools like Jenkins, as well as the two types of actions, developers can make informed decisions on leveraging the full potential of GitHub Actions in their projects.