Author’s note: This blog was written a couple of months ago, before term started. I’ve now started this process set out as below. But I’ve had a lot of feedback from more experienced teachers, and I’m already planning on changing things pretty significantly (“No good plan survives contact” and all that). However, I’m posting this as it’ll be interesting (for me, at least) to document the changes as the year progresses, and to do that I need a baseline!
Situation
Earlier this year, I switched career from working as an SRE to teaching digital apprenticeships at a Further Education college. With my background, I’m first in line to take on the Level 4 DevOps apprenticeship course, and I inherited a small cohort of DevOps students who have completed one year of training. This covered all of the soft skills - collaboration, user-centric approaches, company cultural impacts etc. This has left mostly the technical aspects of the [apprenticeship standard](DevOps engineer / Skills England) to be taught in year 2 - testing, development, deployment, automation etc.
Concept
Being new to the college, I’ve had the luxury of time to prepare for next year. While doing this, I was looking at the KSBs (“Knowledge, Skills, Behaviours”) that remained to be delivered for the DevOps course. I loosely grouped these KSBs into wider topics, and realised that there could be a natural progression that would take a simple core concept of a program through to something approaching production ready.
The course isn’t focused on software development (that’s [this apprenticeship](Software developer / Skills England), so the application doesn’t have to be complicated. But adding things like automated testing, data persistence, CI/CD, monitoring, etc. to a “toy” API service would provide a perfect vehicle for teaching DevOps techniques and concepts.
Plan
So that’s what we’ll do. As a a starting point, each student will be given a very simple API service written in Python. Each student will maintain their own Gitlab project and repository, create stories, design solutions, submit code and nurture their application from “example code” through to a fully pipelined, tested, observable application.
Each new big “feature request” from the Product Owner (me) will be the topic for that week’s discussion and assignment.
Let’s take “Automation” as an example. This topic group covers at least 6 Knowledge and Skill components, and is a fundamental part of the DevOps approach. Students will get some typical teaching on this topic - why do we do this, how do we do this, what does the automation landscape look like at the moment, the concept of pipelines (I can’t avoid mentioning Jenkins here, can I?) etc. All good stuff to spend time teaching in a normal manner. Once the theory is covered, we can then turn to our application and start looking to apply the theory we’ve just covered. What can we automate first? What automation features do we have available? Students will then draw up some stories, create some tasks, and start smashing out some YAML.
And here we find the first example of how applying some real-world controls with DevOps tools can drive student learning. Student’s can’t merge code to their own main branch without a reviewer. All students are invited to collaborate in all other student’s repos, so that they can provide MR reviews. We now have peer-assessment built into the process, which is a useful classroom assessment tool. We also satisfy various skill requirements in the standard. Additionally, we can integrate GitLab into Teams so that review activity is published to a channel for all to see. This should help maintain an air of professionalism to things, and deter unwanted behaviour.
Employers love us making students do presentations, as they know the value of being able to present an idea to your team. The students however, hate doing formal presentations, with many being genuinely extremely anxious about it. In real-world DevOps/SRE teams, there would be opportunity to demo the latest Cool Feature you’ve been working on (or in decent companies that respect their employees, you can demo anything you’ve been “playing with” that might be of interest to the team). Once students have got their code working, they can demo it to their peers in a relatively informal setting. As the educator/facilitator, I can mix this up. It can be mobbed around a single computer, it could be on the big screen, it could be over Teams. It all helps build confidence presenting without having to touch PowerPoint (or Gamma).
Lastly, students will write a short report on the week’s activity. What they did, what they learned, what worked for them, what they might do differently in the future.
Repeat
As we teach in blocks of three days, once a month, we can repeat this process for each new topic:
- a day or two of theory
- half a day of investigating how to apply these concepts
- half a day of drawing up stories and starting work
- homework is to complete the stories, write a report
This will build the application up from simple implementation to a fully-fledged, automated, DevOps beast that may even put some production services to shame!
Assessments
As mentioned, working with Git provides a mechanism for peer-assessment through reviewing Merge Requests. This will need to be monitored to make sure feedback remains positive and encouraging. There’s responsibility for the teacher to foster an inclusive, open and safe learning environment (as we should be anyway). GitLab can be hooked into Teams, so that this discourse gets published visibly for students and the teacher.
Students will write up their work for each particular topic, and the format for this self-assessment will ask the students to reflect on their learning. While this isn’t formally marked, and doesn’t contribute directly to their qualification, it can form a body of knowledge students can use as a revision source before going into their End Point Assessment (EPA). This apprenticeship course doesn’t require students to prove competencies with a portfolio. Additionally, some employers aren’t able to offer students experience in all of these topics.
Potential issues
Students who miss a week for any reason will have a lot to catch up with, which is expected, but there is some burden on their peers (for code reviews) that may be unfair.
There are potentially a lot of spinning plates for the teacher to keep track of, however tight control of the scope for the new features will make sure things remain achievable for all students (in fact, reigning in the highly motivated students will be the difficult part).
Why not do this as a group project?
If the cohort was larger, it would be possible to have students work in small teams on an instance of the application. My gut feeling is that 3 students per team would be the minimum. This lets us do things like pair programming, rotation of duties like scrum master, practice retros, etc. The feature requirements at each stage would need to be large enough to be split into work for 3 students in a meaningful way.
With any group work, there’s going to be a variety of effort from the students. Also it’s feasible that not every student will get sufficient exposure or experience with the given topic, meaning some may miss out on important learning. Rules could be put in place that limits, for example, who gets to write and submit the code, and who gets to document the implementation for each topic covered, but this does mean there’s a lot of potential missed experience for students.