GitHub Actions vs Jenkins, and Self-Hosted Runner vs Github Hosted Runner.

Continuous Integration and Continuous Deployment!!!!!

How was Integration done in the past?

In the past, integration between different tools and systems for CI/CD was typically achieved through custom scripting and manual configuration. Developers and system administrators had to write and maintain their own scripts or use third-party tools to connect and coordinate the different components involved in the CI/CD process.

For example, to integrate version control systems with build servers or deployment tools, developers often wrote custom scripts or used existing plugins or extensions specific to their tools. These scripts would handle tasks such as pulling the latest code from the repository, triggering builds, running tests, and deploying the application to production environments.

What problem does CI solve?

The introduction of dedicated CI/CD tools like Jenkins, TeamCity, Bamboo, and others greatly simplified the integration process. These tools provided built-in integration capabilities for common tools and systems, along with configurable workflows and pipelines. They offered a centralized platform for managing and orchestrating the entire CI/CD process, reducing the reliance on custom scripting and manual configurations.

In recent years, cloud-based CI/CD platforms like GitHub Actions, GitLab CI/CD, and Azure DevOps have further streamlined integration by tightly integrating with popular version control systems, cloud platforms, and other development tools. These platforms often provide pre-configured workflows and easy-to-use interfaces, eliminating the need for extensive custom integration work.

Overall, the shift towards dedicated CI/CD tools and cloud-based platforms has significantly simplified and standardized the integration process, making it more accessible and efficient for developers and organizations.

Let’s look at GitHub Actions and Jenkins, two popular Continuous Integration and Continuous Deployment (CI/CD) tools.

GitHub Actions is a CI/CD platform provided by GitHub. It allows developers to automate their software development workflows directly within the GitHub repository. It is tightly integrated with GitHub and provides a wide range of built-in actions and workflows. GitHub Actions supports multiple programming languages and provides a declarative syntax for defining workflows. It offers easy integration with other GitHub services and has a large marketplace of community-created actions. GitHub Actions is cloud-based and provides scalable infrastructure for running workflows.

Jenkins, on the other hand, is an open-source automation server widely used for CI/CD. It has been around for a longer time and has a large community of users and contributors. Jenkins is highly flexible and extensible, allowing users to create complex build and deployment pipelines. It supports a wide range of plugins that can be used to customize and extend its functionality. Jenkins can be self-hosted, giving users full control over their infrastructure.

When comparing the two, here are some key points to consider:

1. Integration: GitHub Actions is tightly integrated with GitHub, making it seamless to work with GitHub repositories. Jenkins, being a standalone tool, can integrate with various version control systems, including GitHub.
2. Ease of use: GitHub Actions provides a simpler and more intuitive user interface, making it easier to get started with CI/CD workflows. Jenkins, while powerful, can have a steeper learning curve due to its extensive configuration options.
3. Scalability: GitHub Actions is cloud-based and scales automatically based on the workload, making it suitable for small to large projects. Jenkins requires manual configuration and scaling of infrastructure for handling large workloads.
4. Extensibility: Jenkins has a vast collection of plugins that allow users to extend its capabilities and integrate with a wide range of tools and services. GitHub Actions has a growing marketplace of community actions, but it may have fewer options compared to Jenkins.
5. Community and support: Jenkins has a mature and active community, which means there is a wealth of resources and support available. GitHub Actions, although relatively newer, is gaining popularity and has an active community of developers.

Ultimately, the choice between GitHub Actions and Jenkins depends on your specific requirements, familiarity with the tools, and the ecosystem you are working with. Both tools have their strengths and can be effective for CI/CD depending on the context.

Self-Hosted Runner vs Github-Hosted Runner

Self-hosted runners and GitHub-hosted runners are two options available in GitHub Actions for executing workflows. Here’s a comparison between the two:

Self-hosted runner example:

name: GitHub-hosted Runner 

on:
  pull_request:
    branches:
      - feature/*

jobs:
  build:
    runs-on: ubuntu-latest

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

    - name: Build and Test
      run: |
        # Custom build and test commands
        make build
        make test

In this example, the workflow is triggered on a push to the “main” branch. It specifies that the job should run on a self-hosted runner, which you would have set up and configured in your own infrastructure. The steps include checking out the code using a predefined GitHub Action, followed by custom build and test commands specific to your project.

1. Infrastructure control: With self-hosted runners, you have full control over the infrastructure. You can set up and configure your own machines, virtual machines, or containers to act as runners. This allows you to customize the environment to meet your specific needs and requirements.
2. Security: Self-hosted runners can be placed in your own network or infrastructure, providing additional security controls and isolation for your workflows and code.
3. Access to internal resources: Self-hosted runners can access internal resources, such as databases or services, that may not be publicly accessible, making them suitable for workflows that require connectivity to private systems.
4. Scalability and maintenance: Scaling and maintaining self-hosted runners is your responsibility. You need to ensure there are enough resources available and keep them up to date with security patches and updates.

GitHub-hosted runner example:

name: GitHub-hosted Runner

on:
  pull_request:
    branches:
      - feature/*

jobs:
  build:
    runs-on: ubuntu-latest

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

    - name: Build and Test
      run: |
        # Custom build and test commands
        make build
        make test

In this example, the workflow is triggered on pull requests targeting branches that start with “feature/”. It specifies that the job should run on a GitHub-hosted runner using the “ubuntu-latest” environment, which is one of the pre-configured options provided by GitHub. The steps are similar to the previous example, with the checkout and custom build/test commands.

1. Pre-configured environments: GitHub-hosted runners are maintained by GitHub and come with pre-configured environments, such as different operating systems (e.g., Windows, macOS, Linux) and software tools (e.g., Docker). This saves you time and effort in setting up and managing the infrastructure.
2. Scalability: GitHub-hosted runners can scale automatically based on the demand. GitHub manages the infrastructure and ensures there are sufficient resources to handle the workflows.
3. Easy setup: You can start using GitHub-hosted runners immediately without the need for any infrastructure setup or configuration. They are readily available for use with your GitHub repositories.
4. Limited customization: Since GitHub-hosted runners are shared among users, you have limited control over the underlying environment. You cannot install additional software or make extensive modifications to suit your specific needs.

The choice between self-hosted and GitHub-hosted runners depends on your requirements and preferences. If you need full control, customization, or access to internal resources, self-hosted runners may be a better option. On the other hand, if you prefer the convenience, scalability, and pre-configured environments provided by GitHub-hosted runners, they can be a suitable choice. You can also use a combination of both types of runners based on your workflow needs.

I have a simple project here for hands-on https://github.com/youngmind01/Github-Actions

Thank you for reading.

Show some love if this was helpful by clicking the follow button.

Connect with me on Linkedin Promise Imeh