diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 8dd2a570ae43ac761544a2972c94fe48b0af7e5a..6ad91f45afd2e7bd981c8e8aef8357e44b550b08 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -74,59 +74,6 @@ deploy:
     name: production
     url: https://pmpl.cs.ui.ac.id
 
-review-app:
-  stage: deploy
-  image: docker.io/dokku/ci-docker-image:0.9.3
-  # Allow the job to fail when deploying rebased branch
-  rules:
-    - if: $CI_MERGE_REQUEST_ID
-      when: on_success
-      allow_failure: true
-    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
-      when: never
-  variables:
-    BRANCH: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
-    COMMAND: deploy
-    REVIEW_APP_NAME: review-pmpl-course-site-$CI_MERGE_REQUEST_ID
-    GIT_REMOTE_URL: ssh://dokku@dokku-ppl.cs.ui.ac.id/$REVIEW_APP_NAME
-    SSH_PRIVATE_KEY: $DOKKU_SSH_PRIVATE_KEY
-    GIT_DEPTH: "0"
-  script:
-    - dokku-deploy
-  after_script:
-    - dokku-unlock
-  cache: {}
-  dependencies: []
-  needs:
-    - build
-  environment:
-    name: review/$CI_MERGE_REQUEST_ID
-    url: http://$REVIEW_APP_NAME.dokku-ppl.cs.ui.ac.id
-    on_stop: stop-review-app
-
-stop-review-app:
-  stage: deploy
-  image: docker.io/dokku/ci-docker-image:0.9.3
-  rules:
-    - if: $CI_MERGE_REQUEST_ID
-      when: manual
-      allow_failure: true
-  variables:
-    COMMAND: review-apps:destroy
-    REVIEW_APP_NAME: review-pmpl-course-site-$CI_MERGE_REQUEST_ID
-    GIT_REMOTE_URL: ssh://dokku@dokku-ppl.cs.ui.ac.id/$REVIEW_APP_NAME
-    SSH_PRIVATE_KEY: $DOKKU_SSH_PRIVATE_KEY
-    GIT_STRATEGY: none
-  script:
-    - dokku-deploy
-  after_script:
-    - dokku-unlock
-  cache: {}
-  dependencies: []
-  environment:
-    name: review/$CI_MERGE_REQUEST_ID
-    action: stop
-
 dast:
   rules: !reference [.upstream-deploy-rules, rules]
   variables:
diff --git a/docs/2024/exercise1.md b/docs/2024/exercise1.md
new file mode 100644
index 0000000000000000000000000000000000000000..7292f4d1dba46120a410f2c10385aa3cf3ea8bc7
--- /dev/null
+++ b/docs/2024/exercise1.md
@@ -0,0 +1,163 @@
+# Exercise 1: Automated Quality Assurance Activities
+
+You are given a codebase of [a Web app named Sitodo PMPL](https://gitlab.cs.ui.ac.id/pmpl/2023/test-automation-exercise)
+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][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:
+
+```shell
+[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](./images/example_pmd_html.png)
+
+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](#report-template) provided at the end of this document to help you structuring your report.
+
+### Related References for Exercise 1
+
+For completing the exercise above, you can check the following resources:
+
+- [GitLab CI/CD pipeline configuration](https://docs.gitlab.com/ee/ci/)
+- [Maven documentation about the project build lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
+- [PMD documentation](https://docs.pmd-code.org/latest/index.html)
+
+## 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:
+
+- [ ] [Code Quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html)
+- [ ] [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)
+- [ ] [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
+- [ ] (optional) Other relevant CI job template provided by GitLab. Check the list of available CI job templates at https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates
+
+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](#report-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](https://gitlab.cs.ui.ac.id),
+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](https://docs.gitlab.com/runner/executors/docker.html)
+  with [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#privileged-mode).
+  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](https://min.io) 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](https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/infra/kuda).
+
+## Tasks
+
+To guide you working on the exercise, the following are the tasks you need to complete:
+
+1. [ ] Fork the [Sitodo PMPL codebase](https://gitlab.cs.ui.ac.id/pmpl/2024/test-automation-exercise) into your own namespace
+   on [GitLab CSUI](https://gitlab.cs.ui.ac.id) 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](https://www.jetbrains.com/idea/download/) 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](#exercise-configure-generated-report-by-pmd-on-gitlab-cicd-pipeline)
+   and [Exercise 2](#exercise-explore-gitlab-ci-job-templates) 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
+
+```markdown
+# 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.
+```
+
+[PMD]: https://pmd.github.io/
diff --git a/docs/2024/images/example_pmd_html.png b/docs/2024/images/example_pmd_html.png
new file mode 100644
index 0000000000000000000000000000000000000000..e4eef814689e1213b7b26386afaef481a5e840a3
Binary files /dev/null and b/docs/2024/images/example_pmd_html.png differ
diff --git a/docs/index.md b/docs/index.md
index b7de6a6dd799ff2260583e746833964a8f21e055..cfccc39bc197bacecb7832413af434af24963e81 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -18,10 +18,11 @@ Past instructors include:
 
 ## Teaching Assistants
 
-The current teaching assistants in academic year 2023 are:
+The current teaching assistants in academic year 2024 are:
 
-- [Adrika Novrialdi, M.Kom.](#)
+- [Avelia Diva Zahra](#)
 
-Past teaching assistants include:
+Past teaching assistants include (sorted by name):
 
+- [Adrika Novrialdi, M.Kom.](#)
 - [Samuel Tupa Febrian, M.Kom.](#)
diff --git a/mkdocs.yml b/mkdocs.yml
index 14beb8f0b10dab4d617632dce027e36a8598a20c..d8b3ccf1857901176ffae9a7982df686c116af71 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -3,7 +3,7 @@
 site_name: Software Quality Assurance @ CSUI
 site_description: The website for the Software Quality Assurance (SQA/PMPL) course at Faculty of Computer Science Universitas Indonesia.
 site_author: Daya Adianto
-copyright: Copyright &copy; 2023 Faculty of Computer Science Universitas Indonesia
+copyright: Copyright &copy; 2024 Faculty of Computer Science Universitas Indonesia
 
 repo_url: https://gitlab.cs.ui.ac.id/pmpl/course-site
 repo_name: GitLab @ CSUI
@@ -58,6 +58,7 @@ nav:
     - Day 3 - BDD: workshops/day_3_bdd.md
     - Docker Installation: workshops/prep.md
   - Problem Set:
+    - (2024) Exercise 1 - Automated QA: 2024/exercise1.md
     - (2023) Exercise 1 - Automated QA: 2023/exercise1.md
     - (2023) Exercise 2 - Input Domain Modeling: 2023/exercise2.md
     - (2023) Exercise 3 - Monitoring & Load Testing: 2023/exercise3.md
diff --git a/pyproject.toml b/pyproject.toml
index 09bd003e9022d4de22c1ff06698612388d762f4f..2d2c196f239067270cf859d67a4ad102b61d271a 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "pmpl-course-site"
-version = "2023.2"
+version = "2024.10.30"
 description = "The website for the Software Quality Assurance (SQA/PMPL) course at Faculty of Computer Science Universitas Indonesia."
 license = "CC-BY-SA-4.0"
 authors = [
@@ -14,6 +14,7 @@ maintainers = [
 readme = "README.md"
 homepage = "https://pmpl.cs.ui.ac.id"
 repository = "https://gitlab.cs.ui.ac.id/pmpl/course-site"
+# package-mode = false  <-- TODO: Uncomment this after upgrading Poetry to latest version on CI
 
 [tool.poetry.dependencies]
 python = "^3.10"