 As a member of the GitLab community relations team, the GitLab for Education program is close to my heart. GitLab for Education has issued more than one million seats to educational institutions in 65 countries, whether for research, teaching code, hosting student portfolios, or improving the grading and review process for educators, program members are finding new and innovative ways to apply and teach DevOps in the classroom. I'm thrilled to have Robin Manuel from Harriet Watt University here to share what they've learned while using GitLab, including when their classroom went virtual this year. On top of sharing how they're using GitLab across four global campuses, they will also share some of the open source tools they've built to scale the practices they're applying in their classrooms. Enjoy. Hi, welcome to our presentation, GitLab users in the making. And we're gonna talk about the use of GitLab to support programming education at Harriet Watt. I'm Rob Stewart, and I'm presenting today with Manuel Marwick, my colleague. We're gonna cover why we introduced GitLab back in 2018 into our computer science education, what we use it for, how we've implemented a GitLab architecture, and what the outcomes have been since its introduction in 2018. Let's start, first of all, with why we introduced it. In higher education, computer science is a growth area, and that's driven by the needs for graduates in areas like data science, AI, and cyber security. And at the same time, there's another trend for higher education institutes to become global campuses, which is to set up campuses in other places around the world. Harriet Watt University is consistent with both of these trends. We now teach computer science in the Edinburgh campus, which is where we are, the Dubai campus, Malaysia campus, and with a partner, Ocean University in China. Moreover, our undergrad numbers are increasing. So when we introduced GitLab in 2018, our undergrad number was 240. And so we need a system in 2018 that would allow us to become a global campus as well as meet the needs of our growing student numbers. So the aims that we had when thinking of employing GitLab is to scale to these campuses to ensure that assessment at scale with our growing numbers remains efficient to encourage the feedback among students with one another on their coding skills, enable lab helpers to be more effective by giving them mechanisms for formative feedback, as well as to train our students with DevOps skills to prepare them for industry. So the question we asked is, can we use GitLab for an online learning environment to meet these aims? And so what did we use GitLab for is what I'm gonna be explaining to you. So the first thing is we've started, we've transitioned to teaching development, software development using test-driven development. So what we wanted was a platform that would assist us with this, with the intention that the students would get faster immediate feedback on their code and the testing and also reduce the marking time. The second thing that we wanted GitLab for was a way to be able to help and assist students and give them feedback on their code using a platform that facilitates interaction around code. This idea was to improve the feedback on programming and to actually close also the feedback loop with this intention that using a web-based system rather than email exchanges would facilitate keeping track of a discussion with the students and enabling an asynchronous interaction with the student. And so that's the mechanism that we see here is in both direction, the teacher being able to look at the code that the students have committed if they commit early and often and the student being able to ask for help throughout the week and getting help from the lecturers as well as assistants. Another aspect that we were keen to explore with GitLab was to be able to use peer feedback on programming. Having a platform such as GitLab facilitates this management of peer feedback and we've done different approaches to peer feedback. The first one we used a peer code review using a review mechanism with issues in GitLab and templates where students would look at the quality of each other's submission and comments. And the other one using not just a reviewing but also the result of tests would appear testing that would allow students to run the tests that they would have prepared on their peers code. And this was very effective because it stimulates the student to actually prepare better their code but also see how their peers are doing and then exchange with their peers and benefits in both direction with this peer feedback mechanism. So we use templates for that for peer code reviews. And for peer testing, what we've used is a separate platform that would run the tests but then that would present an anonymous discussion around test runs but the notification and the run of tests would then be managed by GitLab. So these are the three main features that we wanted GitLab for, test-driven development, web-based feedback and lab-helping and also peer interactions. So now let's take a look at how we've implemented a GitLab architecture to support those objectives. For a typical university course with programming education, we have a group of students, we have a teacher, a lecturer and some lab helpers. There'll be starter code that the students are given and they work on on their own. There'll also be model solutions to these labs that the teachers have as a basis for guiding students with their formative feedback. So how do we map this typical scenario into the GitLab infrastructure? So what we do at Harriet Watt is create a group for each course that we teach and within that group, we create three subgroups. The first subgroup is for students and we add the student users as members to that subgroup. We also place the starter code into those subgroups, into the student subgroup. The second subgroup is where teachers live. We add them as members, so lecturers and lab helpers and that's where we put the solution code projects as projects into that subgroup. They are private projects so they're not available to the students to see and the last subgroup is for lab helpers. We add the lab helpers members of that subgroup and we add that subgroup as a member of student forks. This allows the lab helpers to see student code and provide feedback on that code when asked. And this scales for multiple courses. So that's one course, but to have another software development course is just a case of creating another GitLab group. So this allows us to facilitate multiple courses within one GitLab instance. So the first thing the student will do is go to one of these starter projects in the student subgroup and then click fork to create their own version of that project. Provided that they commit early and often as we encourage the students to do, lab helpers and lecturers can see the progress of each and every student. They can see what they're working on and when and they can also see the progress according to the unit tests. So they can see when a student has satisfied the requirements of the project according to the tests that have been automatically run by GitLab's continuous integration. Using GitLab dashboard, we can also view across all students how the entire class is progressing with each of their labs. So for a given lab, how many students have forked it and how many have made progress and how many haven't yet forked it. So we can see the progress that are being made, the active students and more or less how many of the students have completed the lab by passing all of the unit tests in each of the lab projects. For that architecture to work, there's various GitLab events that need to take place. For example, adding student users to the student subgroup, adding lab members to student projects, removing merge requests that students might create to avoid plagiarism and all of these actions require intervention. And so that would be laborious, somewhat error-prone, and it really doesn't scale to hundreds of people in a particular class. So we've developed at Heriot-Watt some GitLab software which allows us to automate those things by taking the human out of the loop, both teachers and students. The software is based on a Haskell library that we've developed which allows developers to write GitLab programs as well as GitLab system hooks. The library itself comprises functions to orchestrate a GitLab server as well as data types in which GitLab data will be stored, things like information about users, commits and repositories. So here's an example of a program, a GitLab program written using this library. Very simple program. It looks up a user according to their username and then it looks through all of the projects that that user has created. For each of those projects, it looks up all of the issues and it returns the project with the issues. So if you can read that type signature at the top of this program, this is a program that returns a list of projects for a given user and for each project, a list of issues. One of the things that we've developed using the library is a package called GitLab Tools. GitLab Tools allows you to perform bulk transactions on a GitLab server. For example, at the start of semester, I'm adding all student users to a course group on GitLab. It also has a feature that extracts source code from a GitLab server and submits it to MOS, the plagiarism detection tool to identify any possible plagiarism between different students. It also allows you to download repository archive files for all forks of a given project. The other thing that the library features is a high level API allowing you to write type safe system hooks in GitLab. It's a very simple API and it allows you to pattern match on certain events that take place on the GitLab server in real time. Events such as project creation, an update to a repository, a new user being added to the GitLab server. We use this API to automate those things I mentioned earlier, adding lab helpers to a student fork as soon as the fork is created, deleting and merge request as soon as it's added. Also adding students to multiple course groups as soon as that user creates an account on GitLab. It's important to know though that this API is far more general than a use case for education. This API can be used for a wide variety of different use cases, anything for which real time event driven GitLab programs would find useful. Here's an example of a rule with this event driven API. This is a rule that pattern matches on the event of project creation. And the predicate for checking if to fire this rule is for the created project, if the path of the project is called lab six, then the event that will be fired is to add the group called lab helpers to that event, so to that project. Very simple rule, they can be more complicated according to your needs. It's just a case of writing more Haskell using the GitLab library. But from that previous example, this is in the website what happens. So when a student creates a fork, the lab helpers are added as reporters, allowing them to view the code. But then beneath that, you can see the student is using the at all tag and that sends a message to all members of the project, which of course, the lab helpers. The lab helpers will receive an email with the question and directing them to go back to the website to answer the question close to the code about which the question is being asked. So the software stack for this library, it lifts the REST API from GitLab into functions and types at the Haskell level. It allows you to generate system hook executables. Above that, you can write programs and system hook executables. So we've used the library to build the GitLab tools batch job package, as well as system hooks for the programming courses that we teach at Heriot Watt. But we would hope that other people can come and use the Haskell library for writing their own GitLab programs and their own GitLab system hooks. The open source philosophy that GitLab has very much aligns with the ethos and values at Heriot Watt. So we've open sourced this Haskell library, allowing other developers to use it. So now I'm gonna talk you through the outcomes of using this GitLab at Heriot Watt in our teaching. And so first of all, some numbers. We've contacted students who have been involved using GitLab in their own courses this year, 2020, 2021. And the positive response were overwhelming. The students really enjoyed using GitLab and a vast majority believe that it's improved their way of coding. Then from another point of view, we've estimated that we gain a lot marking time used with the availability of automated testing on GitLab. So that was a gain. In terms of the scale of using GitLab this year, so 2020, 2021, we've been deploying it to 15 courses and these are taught across our four, three campuses plus one plus one partner institution. So this, we looked at the numbers of project that has been created for this academic year and this is the number we have, 13,000, a bit more. But the main thing for us was we started deploying and working with GitLab a couple of years ago and then the pandemic arrived. And what was amazing to us is that having deployed GitLab as an online computer lab facility, we were ready. We were ready, we were COVID ready before when the pandemic hit. We were able to transfer a lot, if not all of our computer lab activity online using GitLab, using the feedback mechanism that Rob explained. So this was, we weren't intending to have a teaching platform for coding that was scalable global. We also had it to be resilient. And the students actually appreciated that a lot. We received a lot of feedback and positive on that aspect. Then what's the gain? What's the benefit? The main benefit for us, I think for the students is that they gain this experience of using an industrial DevOps platform such as GitLab from the moment they start their degrees with us. And the feedback mechanism that the automated testing provides helps them to actually gain confidence. They can see the progress by themselves. They can see where they're heading. So all this, the practice of coding, the practice of receiving feedback very close to the code is highly beneficial to the students. They are able to explain the problem they're having much more easily because the code is there, the test runs are there. And our responses, our feedback, our help is far more purposeful because we can rely on the code and the tests. And of course, even without us setting things up, from day one when GitLab was available to our students, they started to use it to create their own project to do some group work. So that is something they took ownership immediately. Then what are the benefits more if we look at the learning aspects or the point of view that what we believe the students are gaining as well in terms of their learning? The fact that we are able within a course to share some codes, not just as texts in a document but as actionable code that they can fork, that they can also openly access but also that they can run is highly beneficial. Especially for students who have disabilities, the code is available usually before the class and so they're able to follow up at their own pace. The fact that we use this mechanism of feedback online means that the students don't need to wait for the next computer lab session in the room to get feedback. They can ask for the feedback throughout the week of teaching. So that reduces the time to wait for feedback. And then of course with the automated testing that we provide for most of the programming projects or labs what they do is it offers an immediate feedback for the student. And we could see immediately is how much this automated feedback and the Red Cross and Green Tick were motivating students. And this so somehow gives some gamification for free to the learning process. Now, what's the benefit for the teaching team? This was quite important. One of the main thing that we value a lot is with this advice that we give to the student to commit early and commit often, we are far more able to follow up on monitor the progress of the cohort. Then it's of course it provides us a way to share the code, to give feedback more meaningful. It's quite nice not to receive questions from students on their codes by email where you always have to go back and forth to ask for more details. Here you have access to those details if you need. And then one of the very useful aspect of having commit early, commit often is that we can see students working on their project and we can spot common misconception far more earlier. And then we could automate feedback to the cohorts if needed to capture, to explain better these issues that they might have. As we said, it shortens the time significantly. One of the main gain is the fact that the GitLab offers a sort of benchmark of execution. So there's a common platform where the code is run. So we don't have the issue where students can submit codes that only compiles on their machine because of the very specific versions that they're using. And then of course, one of the benefits of providing the tests or asking students to write test upfront is that you have a much more transparent way of talking about the marking criteria in these programming courses. So that's it for our talk. So we've explained why we wanted to use GitLab, what we wanted to use GitLab for, how we've used it in particular, how we've used a statically typed library for interacting with the GitLab API. And then what was the outcome thus far, but we hope to expand on a novel project to use GitLab in our teaching and learning. We're very excited about this work. So please get in touch and here is the link to the library if you want to try it out. Thanks.