Pipelines to perform automation tasks have become a standard in an application lifecycle and have even become a requirement with DevOps adoption. You probably have already heard about Continuous Integration and Deployment and you are using GitHub as a repository provider. Did you know GitHub can also meet your automation needs, with GitHub Actions providing a full out-of-the-box feature?
Hi, my fellow developers,
Pipelines to perform automation tasks have become a standard in an application lifecycle and have even become a requirement with DevOps adoption.
You probably have already heard about Continuous Integration and Deployment and you are using GitHub as a repository provider.
Did you know GitHub can also meet your automation needs, with GitHub Actions providing a full out-of-the-box feature?
In this blog post, we cover the GitHub Actions introduction and dive into the details of a Workflow definition.
First, let’s define CI/CD and explain why we have to differentiate these concepts.
CI refers to “Continuous Integration,” an automation process for development teams. The aim of a CI is to smoothly integrate changes made by different developers and ensure team requirements are reached. CI can run unit tests but also addresses code coverage, bug finding, or technical rules decided by teams (e.g. avoid repeated code blocks). This helps a lot when working with several different branches, maintaining the quality level and improving trust in the code.
Continuous Delivery is the ability to automate code releases by adding gates in the pipelines that ensure the product is ready to go live.
This also means automating some manual steps, such as enabling the process to manage all the security steps for you (e.g. checking, signing, uploading). This can help the deployment run smoothly and improve collaboration between the development and the business teams.
However, CD could also refer to Continuous Deployment, which is a continuous process from creation to production.
In this case, the pipelines will automatically deploy each new version of your application into production after it is passed through checking gates.
Whatever you want to do with your pipelines, you will need to define requirements and processes across all the different teams involved.
Tools such as GitHub Actions, Gitlab CI and Jenkins help you to build these pipelines and integrate them into your CI. Here I will mostly focus on GitHub Actions.
GitHub Actions is a feature provided by GitHub teams to automate development lifecycles. It’s available out-of-the-box with any GitHub repository.
GitHub Actions Components use Events to trigger specific processes.
According to the GitHub Actions naming nomenclature, an Event triggers Workflows composed of Jobs, which execute Steps on Runners. Within a Step, you can execute Actions, which are the smallest components of the GitHub Action framework.
Runners are servers hosted by GitHub (Ubuntu Linux, Microsoft Windows, or macOS), or even your private Runners. It is useful to reuse existing servers or switch to a specific environment.
GitHub Actions Workflows are based on Yaml files that you have to declare in the
.github/workflows folder at the root project level, then commit and push to your Git repository.
Here is an example of a Workflow I have in some of my Monolith sample applications.
name: Application CI on: [push] jobs: run-tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v1 with: node-version: 12.18.3 - uses: actions/setup-java@v1 with: java-version: '11.x' - name: Install node.js packages run: npm install - name: Run backend tests run: | chmod +x mvnw ./mvnw -ntp clean verify -P-webpack - name: Run frontend tests run: npm run test
nameis optional, but I recommend assigning an appropriate name to have a better overview of your Workflows in your GitHub Actions tab.
ondefines Events to trigger the Workflow. In our example, the Workflow will trigger each time a new commit is pushed on any branch of our application.
jobsconsists of the Job list contained in this Workflow. We have included one Job,
run-testsin our Job list.
runs-ondefines the kind of Runner you want the Workflow to run on. Here we’ve selected the last available Ubuntu version.
stepsdefines the list of Steps the Job will execute. Our Steps can either use existing Actions or only run simple bash commands. Using
within an existing Action allows us to pass parameters.
To summarize, this Workflow will be triggered each time a new commit is pushed on any branch, execute a Job named “run-tests” on a Ubuntu server, and perform this sequence of Steps:
You can learn more about this in the official documentation.
If you want to improve your Workflows by reusing Actions provided by the community, the marketplace is the place to visit.
The Actions can be created by the official Actions account, by organizations, individuals, or companies. Calling an Action can help you to execute a specific step instead of writing the commands yourself.
Leveraging Actions is a great way to easily set up your environment (e.g. install a JDK), integrate popular tools such as Docker and Ansible, or call a third-party solution (e.g. Create an issue on Jira).
When you are comfortable with your Workflow definition, I’d recommend checking the Marketplace to explore how to simplify the Yaml file, make the workflow more readable, and reuse existing Actions.
GitHub Actions is free with public repositories. That means you have unlimited automation minutes, while private repositories limit minutes to 2000 per month. Upgrading to a paid plan will grant you access to more minutes for your private repositories (3000 and 50,000 for Teams and Enterprise plans, respectively), and also include more package storage.
You can find more information on this page.
Regarding the usage, some limitations are applied to avoid using too much bandwidth with your Workflow:
This is a good first step into the world of GitHub Actions. We’ve presented the CI/CD concepts, the GitHub Actions overall operation, how to define a good first Workflow, and limitations.
The next blog post will cover a real-world example of how we can create a Workflow based on a real-world project using the Entando Standard Banking Demo.