Skip to content

Exercise 1: Automated Quality Assurance Activities

You are given a codebase of a Web app named Sitodo PMPL that implemented using Java and Spring Boot. The codebase contains both the production code and the test code. The production code is the implementation of all features in the application. The test code comprises unit test suite and functional test suite that covers 97% of the production code when tested locally using Maven.

PMD Static Code Analyser

As part of the exercise, you are asked to modify the existing CI/CD pipeline for performing automated quality assurance activities. Besides running the test suites (i.e., unit and functional tests), the pipeline also runs a static analyser called PMD as part of verify Maven task execution.

The analysis report generated by PMD currently only displayed as log messages in the CI job log, which is too verbose to be communicated to the management or the person with non-technical role. The sample log messages that reporting code quality issues identified by PMD can be seen in the following snippet:

1
2
3
[INFO] PMD Failure: com.example.sitodo.SitodoApplication:7 Rule:UseUtilityClass Priority:3 All methods are static.  Consider using a utility class instead. Alternatively, you could add a private constructor or make the class abstract to silence this warning..
[INFO] PMD Failure: com.example.sitodo.controller.TodoListController:16 Rule:TooManyMethods Priority:3 This class has too many methods, consider refactoring it..
[INFO] PMD Failure: com.example.sitodo.controller.TodoListController:51 Rule:GuardLogStatement Priority:2 Logger calls should be surrounded by log level guards..

It is possible to create the HTML version of the analysis report that much neater for reporting purpose. In fact, the PMD already been configured to produce the HTML report into a file named pmd.html located at target/site. However, it is not yet downloadable as part of the CI artefact. Hence, one of your tasks in this exercise will be modifying the CI/CD pipeline configuration so the pmd.html can be downloaded by the project collaborators.

An example of the HTML report generated by PMD can be seen in the following screenshot:

PMD report example

You may also notice that some rules used by PMD are not relevant to the codebase or even not applicable to Spring Boot. Therefore, you will also need to customise the configuration used by PMD to produce a report with less noise.

To summarise, your tasks related to code quality analysis and reporting using PMD are as follows:

Exercise 1: Configure Generated Report by PMD on GitLab CI/CD Pipeline

  1. Modify the GitLab CI/CD configuration (.gitlab.yml) so the pmd.html generated by PMD as part of the verify Maven task is captured into the CI artefact.
  2. Ensure you can download the HTML report generated by PMD as part of the CI artefact after you updated the CI/CD pipeline configuration.
  3. Look at the HTML report and identify which PMD rules are still relevant to the codebase and PMD rules that may already outdated. For example, StdCyclomatic and ModifiedCyclomatic rules are already deprecated, thus can be excluded from the PMD rules later.
  4. List out the finalised set of PMD rules that you use into your written report file. Then, give two examples of rules that are applicable to another application but may lead to a bad design if applied to Spring Boot application. There is no absolute correct answer for this part. Therefore, it is important to justify your reasoning.
  5. Update the PMD rules by modifying the corresponding PMD configuration section in the project's pom.xml. Make sure, at least, to exclude the deprecated rules.
  6. Try to improve the code quality and security that relevant based on the analysis produced by the CI/CD pipeline. Based on the identified issues, you have to fix the production code and the test code to resolve the issues. Please ensure the code coverage percentage is still maintained above 97%.
  7. Write a short report on your findings and actions to improve the code quality based on the findings from PMD. The report should include the finalised set of PMD rules (task 4), two examples of rules that are applicable to another application but may lead to a bad design if applied to Spring Boot application (task 4), and the actions that you took to resolve the identified issues (task 6).
  8. In addition to the short report, please also write a reflection on your experience making changes to the codebase with existing test suites. Did the presence of existing test code make you more confident in making changes to the production code? Explain why! (at least 2 paragraphs)

The short report and the reflection should be written into the corresponding section specific for this exercise in the EXERCISE_1_REPORT.md file, which should be written into your Sitodo PMPL fork repository. You can refer to the template provided at the end of this document to help you structuring your report.

For completing the exercise above, you can check the following resources:

Explore GitLab CI Job Templates

PMD is one among possible tools that can be used for analysing code quality. There are other tools such as SonarQube, which requires a separate application for analysing and reporting the code quality. To keep stay within the GitLab platform, GitLab also provides several CI job templates that can be included as part of automated quality assurance in the CI/CD pipeline.

Exercise 2: Explore GitLab CI Job Templates

As part of the exercise, you need to modify the existing CI/CD pipeline configuration to include the following CI job template:

For each included CI job template, make sure they run on the CI/CD pipeline of the fork project. Then, write a short report (at least 3 to 6 paragraphs per CI job template) that describes the information produced by each new CI job and how the information can be used to improve the code quality. You should also include releveant code snippet(s) or screenshot(s) to add details into your report.

The short report should be written into the corresponding section specific for this exercise in the EXERCISE_1_REPORT.md file. You can refer to the template provided at the end of this document to help you structuring your report.

Notes: Faculty's CI Infrastructure

For your information when setting up the GitLab CI/CD configuration that will run on GitLab CSUI, the following is the overview of the CI infrastructure in the faculty at the time of writing:

  • GitLab Runner is running on a server using Docker executor with privileged mode enabled. Consequently, all CI jobs running on projects hosted at GitLab CSUI will run in a container by default and able to access the Docker daemon running on the server.
  • The containers spawned by the Docker executor may utilise all CPU cores available on the server, but limited to memory allocation, which is only 8 GB per running container.
  • GitLab Runner has been configured to use a separate Minio cache server, thus allowing caching files and folders across multiple stages in a CI/CD pipeline.

Note: If you are interested with Infrastructure-as-Code (IaC) configuration of the runner, you can find the Ansible playbook used for setting up the server and installing GitLab Runner at Infra Kuda repository.

Tasks

To guide you working on the exercise, the following are the tasks you need to complete:

  1. Fork the Sitodo PMPL codebase into your own namespace on GitLab CSUI and set the visibility of your fork to Internal.
  2. Clone the forked repository into your local development machine and load it into your favourite IDE. We recommend IntelliJ IDEA since the project was built and tested using IntelliJ.
  3. Set up the development environment on your local development machine. You can find the information required to set up the development environment in the project's README.md file.
  4. Ensure you can run the test suite and run the application locally. Follow the instructions in the project's README.md file. For instance, try to run mvn test and mvn package && java -jar <path to the generated JAR file>.
  5. Do the tasks in the Exercise 1 and Exercise 2 sections.

Deliverables

At the end of this exercise, you are required to prepare the following artefacts:

  • A fork repository of Sitodo PMPL project in your own namespace on GitLab CSUI.
  • An updated build configuration (pom.xml) and GitLab CI/CD configuration (.gitlab-ci.yml), in the fork repository.
  • An example of working pipeline in the fork repository that shows the CI/CD pipeline successfully build and test the application.
  • A written report in a Markdown file named EXERCISE_1_REPORT.md in the fork repository.

The due date of this exercise is: 8 November 2024, 23:55 UTC+7. Submit the URL of your fork repository to the designated submission slot on SCELE. Please ensure any updates to the fork repository related to this exercise were made and pushed before the due date.

Report Template

You can use the following Markdown template as a starting point for your report:

Note: you can write your report in English or Bahasa Indonesia

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# Exercise 1 Report

- **Name:** <NAME>
- **NPM:** <NPM>

## PMD Exercise Report

> TODO: Write your report and reflection about PMD exercise here

## GitLab CI Template Exercise Report

> TODO: Write your report about CI template exercise here

## Interesting/Relevant Findings

> TODO(optional): Write down your interesting findings here, if any, that not
> necessarily related to the exercise but still relevant to the SQA as a whole.
Last update: 2024-10-30 13:48:11
Created: 2024-10-30 13:48:11