Github actions is a task runner service managing workflows and implementing CI/CD. As of November 2019 Github officially made the service available to all github users.
Since it’s inception, DevOps engineers have been migrating their CI/CD operations to the actions service for a number of reasons. Why you ask?
CI/CD operations are ran closer (almost native) to source
When using other operation tools such as Jenkins, source code needs to be sent to your self hosted resources. Those resources and tools need then to be setup to manage such connectivity and properly manage what to send where and when.
With Github actions workflows run directly within the Github network on Github resources and integrate directly with all of Github’s platforms. All the management and connectivity Ops engineers used to have to do is now gone. Github provides means to easily make use of your source code, it’s versions, its labels, and meta. There’s default Github environment variables and context variables in every action run to make this management seamless.
There may be a case in which you do need certain operations to run in self-hosted resources, with Github actions this is also possible. Still, the setup and management of self-hosted runners is much simpler than dealing with a tool like Jenkins (more on this topic later).
Cost of operations is cheaper
This point is mutli-faceted. As described in my last point, the cost of managing and setting up self hosted resources practically becomes nil. With that, self-hosted resources that incur monetary expenses are now eliminated. Github does use their actions service as a revenue stream, but users of the service by default are given a fairly heft free tier.
Github charges by the minute a workflow is running. Your workflows can run on different underlying Operating Systems. The OS determines the per-minute rate and if applicable the minute multiplier.
When comparing these prices with cloud provider server prices, taking into consideration free tier limits, you’ll find saving money with Github Actions is very feasible. Personally, the savings in labor for managing operations servers and tools is more than enough ‘cost’ savings to convince me to migrate to Github Actions.
Helps reduce organizational silos
Those in the Ops world know this tenet. It is a core philosophy with in DevOps and SRE. With a tool like Jenkins the barriers to entry for developers–if even assigned to create automation with the tool–can be overwhelming. They need learn the concepts. Then they need to know pipeline syntax. They need to know how jobs and pipelines are organized and follow down stream chains if present. They need to understand how to manage and install plugins. The list goes on. There’s a lot to teach, learn, and overcome to get developers involved with operations ran against their codebases. With that comes the time it takes for Ops engineers to get developers on-boarded and trained to use the tools properly.
With Github Actions developers can immediately start creating workflows in GitHub repositories. GitHub looks for YAML files inside of the .github/workflows directory. Common codebase events developers can grasp like commits, the opening or closing of pull requests, or issues, trigger the start of a workflow. Testing workflows and debug messaging is all within the familiar Github platform. Finally, building out operations is as simple as replicating what a developer would do locally to run, test, and build their software.
Final Notes
The Github Actions hype is real, and theres already so many articles, tutorials, and videos to help get you started. If you are already using Github for version control it’s a no-brainer to start using Github Actions. The tool is so new and getting better everyday. New open source actions are being created daily to do the tasks any of your’s or your organizations projects need. Keep checking in for more posts about action specifics, quirks, and usage.
