Over the past few years, DevOps has become a critical part of the software life cycle, driving the development of many leading DevOps tools and practices. You can find a number of tools that support CI/CD processes, with Jenkins and GitHub Actions standing out among them.
In this article, I’ll compare GitHub Actions to Jenkins and give you insight to make the right choice.
Jenkins and GitHub Action introduction
Jenkins is a free, open source automation server. It helps automate the build, test, and deploy-related parts of software development, facilitating continuous integration and continuous delivery.
Similarly, GitHub Actions is the latest of two offerings that GitHub offers as a SaaS product.
GitHub Actions now makes it easier to automatically build, test, and deploy projects on any platform, including Linux, MacOS, and Windows. Run your workflow in a container or virtual machine.
Before deciding whether a change is worth it, let’s understand who should consider it.
Should you consider moving away from Jenkins?
If you’re using Jenkins and everything is going well, you’re confident in your setup, and you have total control, and cost is not an issue, I would recommend sticking with Jenkins.
For those who use GitHub as a source control platform and are already feeling insecure about their Jenkins setup and looking for a better alternative, GitHub action will be a primary consideration.
Because GitHub Actions is a fully managed service from GitHub, you don’t need to know how to extend and manipulate the infrastructure to run it.
This is the main reason I chose to move away from Jenkins, where I don’t have complete control over what happens to my CI/CD pipes.
Some of the challenges I have had to face:
- Keep plug-ins up to date.
- Even if I didn’t run any builds, my individual Jenkins server builds cost money.
- Inconsistent in aspects such as concurrent builds
- I had to rely on several plugins, and updates came out of them that I had to deal with from time to time.
I knew there was a Jenkins solution that would solve some of these problems, but I had had enough and switched to hosting.
I hope I’ve got the right mindset, and if you’re using GitHub Actions, you can move on to GitHub Actions. Let’s consider this move by looking at the functionality provided by GitHub Actions.
Easy setup — all managed by GitHub
I think the number one advantage of GitHub Actions over Jenkins is the ease of setting up on GitHub Actions. GitHub Actions runs in the cloud, or you can choose to run locally, which is called a runner. Jenkins, by contrast, offers no official management services.
And I probably wouldn’t choose any third party Jenkin hosting products. I felt it was too risky to give access to source code and sensitive information to third party vendors.
For this reason, the Jenkins server needs to be installed, while GitHub Actions does not. Therefore, in GitHub Actions, the setup process is much easier. In addition, GitHub Actions is a series of Docker runs. It requires only docker build and Docker Run, which makes running and debugging very easy.
Tight integration with GitHub — a seamless experience
Initially, Jenkins seemed more flexible than GitHub Actions. Jenkins is primarily account and trigger based and build centric. These do not conform to GitHub Events. GitHub’s actions, by contrast, cover a wide range. Therefore, each GitHub Events has a GitHub Action.
GitHub Actions supports multiple languages and frameworks, which are also written in YAML. As a result, they can be edited, reused, shared, and forked just like code.
It works directly with GitHub because when you forke a repository, the action is automatically forke.
This allows you to test and build projects very efficiently, and even run projects closer to the developers. Plus, you can always access the GitHub API, making it even more popular with developers.
You can see a popular use case for this tight integration when using Bit (Github). Bit is a tool and platform that makes it easy to share JS components (Node, React, Vue, Angular, etc.) from any repository to a Bit’s cloud service, and from there to other repositories.
Bit’s cloud service automatically generates pull requests to all Github repositories affected by a change to a shared component. These automatically generated PR’s can be used as triggers for Github Actions.
This means that changes to a single (shared) component can propagate across all repositories that use it, triggering CI and verifying that all projects are not broken.
Another big “feature” of GitHub Actions is that they can be shared with each other through the GitHub Marketplace. You can reuse actions written by other developers, which can save you a lot of time and avoid rewriting existing code.
Coordinators and build nodes – Scale build
GitHub Actions by default follows the master-slave (coordinator and build node) pattern, rather than the sequential pipeline Jenkins provided for us.
However, it is important to note that a similar setup is possible in Jenkins, but it takes extra effort and knowledge to make it work.
Jenkins vs. Github Actions
| Jenkins | Github Actions |
|---|---|
| The server needs to be installed | No installation is required because it is in the cloud |
| Tasks or work will be synchronous, which will take more time to deploy the product to market | Asynchronous CI/CD is implemented |
| Build centered on non-conforming Github events based on accounts and triggers | Provides actions for each Github event and supports multiple languages and frameworks |
| Need to run on the Docker image to ensure the compatibility of the environment | Suitable for any environment |
| There are plug-ins that support caching | If you need caching, you have to write your own caching mechanism |
| No ability to share | It can be shared via Github Marketpalce |
If you use Jenkins, the default Settings will run each step in the deployment pipeline synchronously. For example, if you need to run unit tests, integration tests, and some Sonar verification, they must be run in a server environment. Depending on the resources available on the server, this may be delayed. In addition, you don’t have to work extra hard to make your pipes reliable.
By using GitHub Actions, these efforts can be parallelized, as shown above, for example, Job 1 can be unit and integration tests, and Job 2 can be verification with Sonar.
conclusion
In terms of its strength, we took a hard look at several areas where GitHub Actions is ahead of Jenkins. In addition, GitHub Actions grew faster than Jenkins, with thousands of GitHub Actions being posted to the GitHub Marketplace. The community is also being improved around, with a dedicated GitHub Actions repository. What does that mean?
However, whether to use GitHub Actions or Jenkins in your project is up to you. Currently, GitHub Actions is free to use for public repositories. For private warehouses, it has a pay-as-you-go mechanism.
I hope you realize that GitHub Actions is an advantage over Jenkins, mainly because of its flexibility. For those starting new projects or using GitHub as their source control platform, turning to GitHub Actions is a great option.
First, the GitHub documentation provides concrete implementation steps, and the GitHub Actions workflow syntax can be found here.
Hope you enjoyed this article. Thanks for reading!!
Original text: blog. Bitsrc. IO