Have you ever wondered how moving your Jenkins workflow to GitHub Actions could benefit your software development process? In this article, we will explore the valuable insights gained from transitioning Jenkins to GitHub Actions.
CI/CD Tools
In the world of software development and deployment, Continuous Integration and Continuous Deployment (CI/CD) tools play a crucial role. These tools automate the process of integrating code changes and deploying applications, ensuring faster delivery and improved software quality. Among the various CI/CD tools available, GitOps has emerged as a popular approach that aligns development and operations through Git version control.
While traditional tools like Jenkins have been the go-to choice for many years, newer options like GitLab CI and GitHub Actions have entered the market with their own advantages. GitHub CI, in particular, stands out for its seamless integration with GitOps principles, offering tighter control and management of code changes.
Today, we will be discussing the process of migrating from Jenkins to GitHub Actions. Despite their decade-long gap, both tools have unique capabilities and challenges. By exploring this transition, we can gain valuable insights and learn from the experiences encountered along the way.
What are those tools for and why migrate?
Jenkins is an open-source automation tool used for continuous integration and delivery (CI/CD). It’s built using a specific language called Groovy, requires managing its own and infrastructure, and is made in a way that there should be one per organization.
GitHub Actions exists on top of GitHub, which is usually where code is managed at many organizations. You can use it to create workflows based on certain actions and so it can also be used to build and deploy software. GitHub Action is managed by GitHub, and relies on underlying infrastructure from Azure. It’s however possible to delegate this with your own hardware for workflows.
Why migrate Jenkins to GitHub Actions
Migrating Jenkins to GitHub Actions is crucial because it enables seamless integration and automation of software development workflows. This shift improves code deployment processes, accelerating project delivery. It also reduces attack surface, as Jenkins is one more resource to manage in an organization space, with high stakes as it has access to many other parts of the system. Finally, as each workflow runs independently on GitHub actions, you don’t run in the same concurrency bottlenecks you do with Jenkins.
We did such a migration for the client. We learned a few things, especially that it takes time to plan the migration and that you have to allow the workflows to develop properly or be prepared for some things to go wrong. In this article, we will discuss the usual steps for a migration like this.
Jenkins architecture is complex
Where to start the migration?
The first thing you need to do is make a list of all the pipelines, projects, and environments that are connected to Jenkins. You should also try to figure out what credentials and network permissions will be needed in the future. It’s important to know if there are any limitations with the network or if there are things that can’t be done from outside the internet.
Once you have all this information, you can start finding solutions to any problems. It’s also good to estimate how much Jenkins is costing you and what the current setup can do at the same time. Compare with GitHub actions pricing to make an informed decision.
Planning ahead
To organize tasks and gather workflows, communicate with stakeholders and include it in the project management as a deliverable. It’s important to be aware that this process may take time, so allocate a disruption budget accordingly.
Consider creating a dedicated test environment and try to identify different workflow archetypes. For example, in our situation, there were three archetypes: backend deployment to Kubernetes, frontend deployment to Kubernetes, and frontend static deployment to CDN. Ideally, disable test environment flows for Jenkins to assess the level of disruption you may encounter when enabling them.
Executing the migration
To simplify the process, it is recommended to start by thinking in archetypes rather than directly converting Jenkinsfile into GitHub Actions workflows. This is because Jenkins events and GitHub events have different logic. Begin by listing the logical dependencies required for deployment, considering what a developer would do from their own machine.
GitHub actions offers more flexibility than Jenkins in terms of when you want to run workflows. It provides better support for the pull request process and includes events like releases, which are not available in Jenkins.
Utilize GitHub Packages, which are external projects that can be used with GitHub Actions by passing arguments to execute complex tasks such as deploying to Kubernetes or executing actions with Docker. Think of these packages as similar to Jenkins modules.
The next step involves separating the core flow from the components that differentiate environments and projects. One approach is to use separate YAML files for each environment and project, while providing the same set of standard environment variables at the start of the flow to maintain readability. This strategy may be more sustainable than trying to consolidate all the code, despite the potential duplication. If you encounter difficulties in finding the appropriate packages to import, consider looking at what others have done.
A typical kubernetes deployment flow with Github actions and keel
Continuous Improvement
To improve the flow of your workflows, consider leveraging the cache feature of GitHub Actions. This is particularly useful when performing tasks like Docker builds or importing packages. Many GitHub packages or setup steps already include built-in logic for caching, so it’s important to identify which content can be reused between builds.
Additionally, when using a package, it is recommended to bind it to a specific tag or commit number. This adds an extra layer of security, especially for critical workflows, as it helps prevent any potential harm that may occur if the third-party repository is compromised, and malicious code is injected into a new version.
To enhance tracking and reporting, ensure that you send relevant information to your monitoring systems or communication platforms like Slack, Teams, or emails. This will help keep you informed about the progress of your builds. Furthermore, take advantage of the convenient integration with Jira. By correctly naming your branches, you can easily associate deployments with specific Jira tickets, offering a seamless and organized workflow management solution.
Assessing success and Conclusion
By now, you’re almost finished with Jenkins. Any remaining tasks can be dealt with later. You’ll experience significant cost savings with the pricing structure, as you only pay for actions by the second, unlike Jenkins which needs its own server. Additionally, the integration of GitHub Actions in GitHub itself will likely enhance organization efficiency and developer comfort. Wishing you a smooth migration!