2. Analysis of existing solutions

This chapter defines the problem addressed by the proposed tool. The aim is not to create another programming-submission system or assign grades automatically. The subject of observation is the workflow already recorded in GitLab projects: issues, branches, merge requests, reviews, tests, and CI/CD processes.

2.1 Problem context

DevOps combines technical practices with teamwork. An automated build or deployment has limited educational value if a student cannot divide, document, review, and correct a change using feedback. Research on DevOps education therefore emphasises practical work in a continuous process rather than familiarity with isolated tools.¹²³

Research on code review reaches a similar conclusion. Review supports both defect detection and knowledge sharing.⁴ A comment count is therefore not a reliable substitute for expert judgement. A tool may verify that a discussion occurred and that the author responded, but a person must still assess the meaning of the feedback.

2.2 Teaching workflow

Software Engineering Fundamentals and DevOps Fundamentals use GitLab for team assignments.⁵⁶ A student works from an issue, creates a branch and merge request, adds tests, involves peers in review, and checks the CI/CD result. Evidence of this process is spread across several objects. The instructor must combine them and repeat the same inspection for multiple projects.

Course requirements can be decomposed into technical questions R01-R13. They cover issue assignment, a working branch and merge request, tests, linked objects, reviewer participation, author responses, approval, and a successful CI/CD process. The results do not have equal certainty. Pipeline status is a directly stored fact, while comment quality and code quality still require manual assessment.

2.3 Existing categories of solutions

Automated assessment systems

Artemis combines exercises, repositories, builds, tests, and feedback in a controlled educational environment.⁷ It is suitable for repeatable verification of a functional result. This thesis must instead operate over existing GitLab projects and observe team history across several object types. Branch-based review teaching is closely related, but it does not provide a course-wide overview.⁸

GitLab analytics

GitLab provides analytics for contributions, merge requests, issues, and CI/CD processes.⁹ Data retain their connection to the source artefact, but an instructor must still map them manually to course criteria. Native analytics do not directly answer whether each member reviewed the required number of changes and responded to feedback on their own merge request.

Checks on an individual change

Danger evaluates rules for one merge request and posts the result in its discussion.¹⁰ SonarQube applies static analysis and quality gates to source code.¹¹ Both provide fast feedback, but neither follows one student's history across multiple projects and course objects.

2.4 Comparison and identified gap

✓ - directly supported, ~ - partially supported or requires an extension, - - outside the solution's purpose.

The table does not imply that these tools are incomplete for their intended purpose. The gap appears in this teaching context: projects already exist in GitLab, the instructor needs a view across them, and every result must remain a verifiable indicator rather than an automatic grade.

The proposed solution therefore adds a thin educational layer over GitLab. It maps available data to R01-R13, allows an instructor to select checks and thresholds, highlights groups requiring attention, and preserves navigation to the source artefact. Implementation quality and actual understanding remain subjects of manual assessment.