GitHub Actions: Pipeline-as-a-Code Building Blocks Rising
-
4154
-
14
-
38
-
0
Although the Pipeline-as-a-code technique is commonly enforced by the bulk of CI/CD platforms, GitHub Actions might take this service to the next level with its Pipeline-as-a-Code Building Blocks model. Why open-source Pipeline-as-a-Code Building Blocks is more than just another CI/CD tool and how GitHub Actions embarked on a new wave in CI/CD evolution will be discussed in this article.
How GitHub Actions help automate SDLC
If your desire to create an offbeat workflow in your GitHub repository seems a bit challenging, Github Actions is the perfect platform to implement this daring project. You simply create workflows of tasks aka actions that are automatically operated on particular events. That is how you easily incorporate continuous integration (CI), continuous delivery/deployment (CD), and lots of other valuable life cycle rounds into your repository. What benefits GitHub Actions furnish:
- GitHub insider. You do not need any outer site to deal with GitHub Actions because it’s totally mingled with GitHub which means you do not need to change the place to operate your brand-new flows.
- Myriad-container setup & testing. You just need to add Docker-compose files to your new flow for actions to set up and test numerous containers simultaneously.
- Abundant CI patterns. Here you can find lots of CI samples of all kinds and composition models with the possibility to design your own custom template of course. By the way, your templates can be published as a new Action on the Github Marketplace.
- Any-server-friendly. After you create your flows either by composing blocks/steps in the visual editor or writing them yourself using YAM, you can use GitHub’s, another provider’s or your self-hosted server to run them.
- Real-time logging+continuous monitoring. You can watch your workflow live running spiced up with color and emoji. And just in one click, you copy a link that highlights a specific CI/CD failure to share it immediately with the team.
- Any-OS-friendly. Whatever OS you have: Linux, macOS, or Windows, GitHub Actions work with it. You can operate in a container or virtual machine, utilize your own virtual machine on cloud or on-prem — everything will work with Actions.
- Any-language-friendly. GitHub Actions works with any programming language (Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET, etc.) you choose for your product.
- Easy-share/scale/update. Being stored in a repository, it is easy to share and scale flows within or across projects.
- Community-supported workflows. GitHub Actions bring together all of your tools to automate every phase of your SDLC. You do not need to reinvent a wheel; you just leverage the vast number of open libraries accessible on GitHub to develop your tasks for your custom flows.
- It’s free! Actions present 2000 charge-less build minutes a month for all your private repositories which puts GitHub in the vanguard compared to most CI/CD platforms.
How Pipeline-as-a-code Building Blocks popped up or three stages of CI/CD evolution
With DevOps, businesses focusing on streamlining and automating software development processes at most, they are eternally in search of best CI/CD tooling. How CI/CD platforms evolved? In our humble opinion, three distinct steps or stages of CI/CD development can be named. Let’s trace them down:
1 stage — Jenkins at your service!
“I was busy implementing the JAXB RI, I must have broken one too many builds… Wouldn’t it be nice if I can have a program to make sure that the workspace is always built?”
Kohsuke Kawaguchi, staff Engineer at Sun Microsystems, creator of Jenkins
Back in 2007 Hudson (Jenkins) took over Cruise Control and other open-source build-servers and proved to be the top automation server for all phases of SDLC promoting CI/CD. At the JavaOne conference in May 2008, the service even earned the Duke’s Choice Award in the Developer Solutions tier. After a brawl with Oracle, in 2011, Hudson was retitled to Jenkins. Jenkins was and undoubtedly is a premium CI/CD platform and certainly distinguishes the first step of CI/CD expansion, which is CI/CD adoption (only before the Jenkins Job DSL plugin turned up)
2 stage — Pipeline-as-a-code? Be my guest! With the Job DSL plugin, the first stage of CI/CD growth was over. The Job DSL plugin — and later the Jenkins 2.0 pipeline project in 2016 — can be considered the second stage of CI/CD platforms development. Why? Well, Jenkins is an excellent tool for operating builds, but specialists tend to utilize UI to configure jobs. Jobs, when growing in number, make maintaining them impossibly laborious and exhausting. What’s more, the solution of job duplication failed as these “clones” differentiated from their masters and therefore it became harder to sustain their coherence. The Job DSL plugin tackled this issue by enabling jobs to be described in a programmed form, in a human-coherent file. But, as for me, Jenkins actually was not the following CI/CD phases’ kinetic energy.
Travis CI, released in 2013, aiming at providing free CI/CD services for open source projects has made a gigantic step towards pushing the next evolution round forward. How exactly? With Travis CI and GitHub’s marriage, the emerging system can be seen as a precursor to current software development techniques, when engineers are responsible for writing a couple of lines of code, composing pipelines, and building an application.
In 2018, GitLab CI fetched the IT industry the capacity and efficiency of CI/CD pipelines that we only got from Travis CI. GitLab CI also solved the problem that we faced with most of the Pipeline-as-Code platforms. Released in version 11.7 in early 2019, GitLab CI has made one giant leap by injecting the include keyword into their pipeline syntax. With that, reusable pipeline patterns were translated into reality. Jenkins also made it possible with their pipelines, however, some experts find these solutions a bit unrefined.
Atlassian Bamboo and Bitbucket Pipelines, correspondingly on-premises and SaaS CI/CD tooling versions are good for users favouring self-hosted solutions. The problem is that the Bamboo/Bitbucket fee might be a little too much especially for SMB and startups. Indeed, there is no one-size-fits-all tool. Still, a period when Pipeline-as-a-Code stepped on a scene and CI/CD platforms picked up the trend can be acknowledged as the second stage of CI/CD evolution.
3 stage — Lights, camera, action! In late 2019, GitHub revealed the accessibility of GitHub Actions. “Who cares? It’s just one more CI/CD tool,“ everyone thought and was wrong. Well, yes, it’s definitely one of the outstanding CI/CD platforms, but one element was added that segregates it from the others. And it’s straight in the title: Action! Just take a look at the GitHub Actions Marketplace. All the actions here are provided not only by GitHub but also by other companies in the community. One way or another they are here absolutely available on GitHub. Assembling like well-known Lego building blocks, these actions tackle common, rather painful issues from how we are supposed to reuse what we have written here to how we deploy our application to this new cloud service using Infrastructure-as-Code when writing CI/CD pipelines. These and many other features are already covered by accessible GitHub Actions. What’s more, if you want your code lines to be drastically reduced in number — turn to GitHub Actions. With each Action version number attached, you do not need to have a headache that your pipelines will be spontaneously altered. The upgrades are clear-cut and fully automated. Additionally, if by extraordinary coincidence, you cannot find an action you need, you can always write and publish one.
Final thoughts
To wrap things up, we think that GitHub Actions start a new level in CI/CD platforms expansion. With Actions, we can cut our gigantic code in half and we don’t need to support in-house teams to write reusable templates. We just find the already published action and use it. Surely, GitHub will not be the only company adopting the Pipeline-as-a-Code Building model, however, so far only GitHub widely enforces it. Try GitHub Actions for your next project. If you find it challenging and have any action/DevOps-related questions you can always turn to us and we will consult you on any issue you have.