{{announcement.body}}
{{announcement.title}}

Automate Your Development Workflow With Github Actions

DZone 's Guide to

Automate Your Development Workflow With Github Actions

In this article, we show you how to automate your development workflow with Github Actions to have your version control and CI/CD platform in one place.

· DevOps Zone ·
Free Resource

Hi everybody. My name is Hacene. I am a software developer and interested in DevOps. Today, I will show you how to automate a development workflow life cycle using Github Actions.

On November 13, 2019, Github engineers revealed some news: GitHub Actions is supporting CI/CD now, and it's free for public repositories! We can manage and automate our development workflows right in our repository using GitHub Actions. The API supports multiple Operating Systems (Linux, Windows, MacOS…) and different languages.

In this article, I will give you an example of a CI/CD pipeline using Github Actions for Spring boot 2.x (java 8) web service

Introduction

The idea is to automate the development workflow by building a CI/CD pipeline using Github Actions. The aim is to deploy a Spring Boot web service on a remote server. We will use a succession of jobs to build, test, generate code coverage report, and deploy our code right from GitHub. The generated package will be deployed on the remote server. 

CI/CD pipeline

There are two ways to create a required workflow file :

We can create a workflow in our Github repository. The YAML file must be stored in the .github/workflows directory in the root of our Github repository. The workflow must have at least one job that contains a set of steps that perform individual tasks. Steps can run commands or use an action. Our workflow file should respect a YAML syntax and must have either a .yml or .yaml file extension. If you want to learn more about YAML, see "Learn YAML in five minutes."

Initial project structure

By creating a workflow file in the Actions section on GitHub repository, we choose maven workflow :

Workflow Actions
Java with Maven

When we click on Set up this workflow, we will see the pre-filled maven workflow below:

Maven workflow

The jobs are based on Matrix builds. A matrix build can generate at most 256 jobs per workflow run.

We configure a workflow to start when a GitHub event occurs. The jobs will be triggered after pushing code or making a pull request on the master branch. The main job in this example is the launching mvn package command. As it's specified in the YAML file, we have to commit the changes to the master branch.

Testing the Workflow

Let’s test it and see what happens …

Testing application workflow

After launching the workflow process, the configuration executed will define some actions that should be performed inside the Ubuntu container. The job makes a checkout of my git repository on the master branch and sets up a JDK 1.8. Then, it starts the mvn build command and puts up the required Maven packages included in my pom.xml. Finally, it runs the tests and generates the JAR file.

Here are some limits about using Github Actions, check this link.

Enhancing the Workflow

Now, we will divide our workflow into different jobs:

compile job: checks out the Github source code and compiles it.

test job: runs unit tests (it requires a compile job). 

build job: runs the mvn build command and generates the code coverage report, which will be sent to codecov.io

Below is the complete file:

YAML


We use encrypted secrets that allow us to store sensitive information. A field CODECOV_TOKEN, is a token retrieved from codecov.io. It's persisted as a secret in the Github environment.

Once the actions have been performed, we can see the result in the Actions tab:

Checking Actions tab


In the last step, we need to add a job to deploy the jar file on the remote server. This job is pretty much the same as the preceding ones. We have to copy the executable file to the remote server; this operation is based on SFTP protocol. 

To get this working, we will use actions shared by the GitHub community, and we will customize them as needed, garygrossgarten/github-action-scp@release and fifsky/ssh-action@master. Then, we have to add the secrets (environment variables for ssh connection) on the Github secrets section of our repository. 

These variables will be available in the container that was started with Github Actions:

Github Secrets session


Adding a job to deploy the executable file:

YAML


The result looks like this :

Deploying application


After deploying and running the container using Postman, we call an exposed endpoint:

Calling endpoint via Postman


Everything seems to be working. Now, we add the well-deserved badge markdown on our README.md.

Shell
Java CI with Maven

In the README.md file, the result looks promising :

Final README.md file

Conclusion

I hope that you have enjoyed the post and learned how to use Github actions to automate your CI/CD workflow.

Personally, I used to work on a CI platform with Jenkins that required a lot of prerequisites to set up the workflow. So, I’m pretty surprised how well the CI/CD pipeline is working, flawlessly, and quickly using Github Actions. We can take advantage of this flexibility to create and maintain customized development workflows to automate the software development lifecycle processes.

You can find the mentioned project on GitHub, you can also ask me your questions on my blog.

Topics:
ci/cd pipeline, continious integration, craftsmanship, devops, github actions, workflow automation

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}