goodbye jenkins

Hello GitHub Actions, Goodbye JAAnkins: Open Source North conference 2023

—

by

MJ
in

TDLR; If the day ends in Y, it’s a perfect day to ditch Jenkins and migrate your CICD to something less crappy, like GH actions. This is the summary of a talk I prepared for Open Source North conference in May 2023.

open source north tweet

When we talk about migrating an application CI/CD pipeline from Jenkins to GitHub Actions we’re really talking about trading in the problems inherent to Jenkins for a simpler and more modular tool set. Jenkins has been the go-to CI/CD tool for a long time, but it has a lot of drawbacks.

The problem(s) with Jenkins

  1. Steep Learning Curve: Jenkins has a steep learning curve, which can make it difficult for users who are new to the platform to get started.
  2. Configuration Overload: Jenkins requires a significant amount of configuration, which can be overwhelming for users who are not familiar with the platform.
  3. Plugin Management: Jenkins has a huge ecosystem of plugins, which makes it tricky to manage and update. You have likely encountered compatibility issues or plugin conflicts that disrupt CI/CD pipelines.
  4. Maintenance and Upkeep: Jenkins requires regular maintenance and updates to ensure that it is running smoothly. This can be time-consuming, and you end up spending a lot of time making sure your pipelines are running correctly.
  5. Limited Scalability: Let’s face it, Jenkins is sluggish almost all the time and especially when used at scale. This can be a problem for large companies that need to run lots of pipelines simultaneously.
  6. Security Concerns: Jenkins puts a lot of the onus on users to ensure that pipelines are adequately protected.

The GitHub Actions Alternative

Here are some of the top features of GitHub Actions that I think make it a better option than Jenkins for CI/CD pipelines.

  1. Easy to use: GitHub Actions is easy to use and understand, especially if you’re already familiar with GitHub. It’s YAML-based, lives in your repo and there’s no need to deploy infrastructure or spend a lot of time configuring.
  2. Scalable: GitHub Actions can handle any size of the project, whether it’s a small project or a large enterprise application.
  3. Native integration: GitHub Actions is natively integrated with GitHub, making it easy to configure and manage pipelines within the same platform. And you have full visibility into workflows as they execute with the ability to configure notifications if something goes wrong in a particular stage.
  4. Large community: Probably the best part, GitHub Actions has a large community of contributors and users who are constantly adding new features, fixing bugs, and sharing best practices.

Migrating from Jenkins to GitHub Actions

Let’s talk about what it would look like to migrate from Jenkins to GitHub Actions.

  1. Create a GitHub repository: Create a new repository on GitHub for your application if you haven’t already.
  2. Add a GitHub Actions workflow: Create a new GitHub Actions workflow file in your repository. The workflow file is written in YAML and contains the steps for your pipeline.
  3. Configure the workflow: Configure the workflow, you can add steps for building, testing, and deploying your application.
  4. Run the workflow: Once you have configured the workflow, run it to make sure it’s working.
  5. Refine the workflow: Refine the workflow as necessary, adding more steps or tweaking existing ones.
  6. Ditch Jenkins 🙂 Once you’re happy with the GitHub Actions workflow, you can drop the Jenkins pipeline.

Example: Building a Node.js application with GH actions

name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js 14.x
      uses: actions/setup-node@v1
      with:
        node-version: '14.x'
    - run: npm install
    - run: npm run build
    - run: npm test

Breaking it down

Triggers

The top of the file defines when the workflow should be triggered. It specifies that the workflow should run:

  • On every push to the repository’s main branch.
  • On every pull_request created or updated against the main branch.

Jobs

The jobs section defines a single job named build, which will run on a virtual machine (runner) with the latest version of Ubuntu.

Steps

These are the individual steps that the job will execute sequentially.

  • uses: actions/checkout@v2 checks out the repository’s code.
  • name: Use Node.js 14.x sets up Node.js version 14.x for the environment.
  • run: npm install installs the Node.js application’s dependencies.
  • run: npm run build runs a build process for the application.
  • run: npm test runs tests for the application.

To wrap, GitHub Actions workflows can be triggered by lots of different things (in this case on pushes and pull requests to the main branch). It can run one or many jobs on user selected base machines, allow us to checkout code, set up a runtime, install dependencies, build an application, run tests and more! I hope this helps you see why I prefer GH actions to Jenkins. If you’re looking for the next level of inception you can read about Ansible and how you can deploy Ansible using GitHub Actions.

A while back I had the opportunity to help a fortune 5 company with a multi-team migration from Jenkins to GH actions for their pipelines. If you’re thinking of migrating, reach out. I’d be glad to share what I’ve learned.