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 PMD are as follows:

  • Modify the existing CI/CD pipeline so the pmd.html generated by PMD as part of the verify Maven task is captured as part of the CI artefact.
  • Ensure you can download the HTML report generated by PMD as part of the CI artefact after you updated the CI/CD pipeline configuration.
  • 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.
  • List out the finalised set of PMD rules that you use into the bottom section of your README.md of the codebase. 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.
  • Update the PMD rules by modifying the corresponding PMD configuration section in pom.xml. Make sure, at least, the deprecated rules are excluded.
  • 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%.

Exploring 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 require 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.

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

Once you have updated the configuration, look at a CI/CD pipeline that has run and see what kinds of information produced by the included CI job templates.

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 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 test and run the application locally.
  5. Update the CI/CD pipeline configuration in the codebase according to the tasks mentioned in PMD and CI job template sections.
  6. Identify code quality and security issues, then resolve the identified issues.
  7. Write a short report at the end of the project's README.md that describes:
  8. List of identified code quality and security issues in the codebase.
  9. Explanation on how you resolve at least two issues identified by PMD in the codebase. You can explain it by comparing the diff of the codebase and explain the changes you made.
  10. Reflection on your experience making changes to the codebase with existing test suites. Did the presence of test code make you more confident in making changes to the production code? Explain why!

Additional Tasks

Explore and implement SonarQube in your CI/CD pipeline. Use SonarQube CSUI. You can read more details and relevant config on the website.

  • Modify pom.xml with SonarQube relevant config
  • Add a CI/CD pipeline to run SonarQube scanner task
  • Improve the code quality based on the SonarQube scanner result.
  • Summarise your findings in the bottom section of the README.md

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 GitLab CI/CD configuration, i.e. .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.
  • An updated README.md in the fork repository.

The due date of this exercise is: 10 November 2023, 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.

References

Last update: 2023-11-01 15:22:34
Created: 2023-11-01 15:22:34