Observability in DevOps: A Practical Guide to Implementing It

Code quality is a vital aspect for any development team. However, constantly carrying out manual code reviews can be inefficient and prone to human error, or worse still, not reviewing it and only settling for it to work allows us to work with bad practices within the organization. This is where GitHub Actions offers a solution to automate much of the review process, helping to maintain high quality standards without sacrificing efficiency.

In this practical guide, you'll learn step by step how to take advantage of GitHub Actions to implement automatic and effective code reviews on each pull request (PR) and how to set up automated flows integrating popular static analysis and unit testing tools into your Java project using GitHub Actions.

You'll learn how to integrate tools that analyze code style, detect common errors, identify potential bugs and measure test coverage, and create an automated checklist to ensure that each PR complies with the standards established by your team.

🤖 Why automate the review of Java code?

Automating code review processes offers multiple advantages:

✅ Consistency: Avoid human errors and ensure that each revision follows the same standards.

✅ Speed: It allows you to quickly detect common errors before merging to the main branch.

✅ Efficiency: Frees developers from repetitive tasks to focus on more complex issues.

✅ Best Practices: Get developers used to implementing good practices in their code in every PR.

💻 Prerequisites before starting

To follow this guide, you'll need:

• A Java repository hosted on GitHub.
• Java JDK 8 or higher configured in your project.
• Basic familiarity with YAML, Maven, or Gradle.
• Access to create workflows in GitHub Actions.

⚙️ Configuring GitHub Actions

GitHub Actions workflows are defined in YAML files stored in the .github/workflows folder. Below is the guide with the necessary steps to set up your first workflow.

Step 1: Create the workflow YAML file

Create the .github/workflows/ci-java.yml file and define the basic structure:

This file configures a basic flow that is activated in each PR directed to the main branch, but it can also be changed to other branches as the case may be.

Step 2: Integrate static analysis with Checkstyle

Checkstyle is a tool that allows you to analyze the source code of your Java files so that it complies with certain style rules and conventions defined by the team.

It does not detect functional errors like a compiler, but rather aspects such as:

✅ If the names of classes, methods, or variables follow a convention (such as CamelCase, PascalCase, etc.)
✅ Whether the code blocks are properly indented
✅ If there are lines that are too long
✅ If there are unnecessary spaces or line breaks
✅ If documentation is missing in classes or methods (Javadoc)
✅ Among other details of Clean Code

To integrate it:

First, in your Maven or Gradle project, add the dependency Checkstyle.

For Maven:

Define the rules in a configuration XML file, for example checkstyle.xml, in this one you can add the rules, for example, for the maximum length of characters in a line:

Then, add this step to your YAML workflow:

Step 3: Integrate PMD for advanced faulty code detection

PMD is another powerful static analysis tool for Detect problems potentials like:

🔍 Common logic errors
❌ Bad programming practices
📉 Duplicate or unnecessary code
🚫 Using unused variables
🧠 Excessive complexity in methods or classes

To configure it, add the PMD dependency in Maven:

Define the rules in a configuration XML file, for example quickstart.xml, in this one you can add the rules:

Then, add to the workflow:

Step 4: Detect errors and vulnerabilities with SpotBugs 🐞

SpotBugs is an effective tool for detecting potential bugs, logic errors, and security vulnerabilities before the code is executed. SpotBugs does not analyze the source code directly, but rather analyzes the .class compiled.

This allows you to do deeper analysis, including execution flows and bytecode patterns.

To configure it add the plugin to the pom.xml:

Then, include this step in your workflow:

Step 5: Integrate code coverage with JACoCo

JacoCo measures the Coverage of unit tests.

Add it to the pom.xml by defining the minimum percentage of test coverage:

Then, run the unit tests with coverage from your workflow:

Step 6: Create an automated checklist

Now that you have completed the previous steps, you can create an automated checklist in GitHub Actions using the Status checks. GitHub will automatically display the results of these steps in the PR interface, indicating whether each automated review passes or fails.

The entire workflow should look like this:

🔍 How to interpret and resolve the results 📊

When you open a PR, GitHub Actions will automatically execute these steps. If any fails, the log can be accessed directly from GitHub and the reported issues can be corrected before merging the PR. This ensures that only high-quality code reaches the main branches.

📘 Best Practices and Additional Recommendations

• Keep your workflow and dependencies up to date.
• Customize the Checkstyle and PMD rules according to your needs.
• Promote early attention to automated results in your team to reduce technical debt.

Conclusion

Automating the quality of Java code using GitHub Actions is an effective strategy for maintaining the consistency and quality of the source code. By adopting these tools and practices, common problems can be detected quickly, manual efforts can be significantly reduced and equipment efficiency can be significantly improved.

Start implementing these robust automated processes today and take the productivity and reliability of your Java project to the next level.

It's time to automate and optimize your Java code review!

Do you want your DevOps team to stop putting out fires and start preventing them? 👉 Contact us and we'll help you build an effective observability strategy adapted to your system.

‍