Content uploaded by Richard Hobeck
Author content
All content in this area was uploaded by Richard Hobeck on Sep 16, 2021
Content may be subject to copyright.
Teaching DevOps: A Tale of Two Universities
Richard Hobeck
Ingo Weber
Software and Business Engineering
Technische Universitaet Berlin
Berlin, Germany
firstname.lastname@tu-berlin.de
Len Bass
Hasan Yasar
Carnegie Mellon University
Pittsburgh, Pennsylvania, USA
lenbass@cmu.edu
hyasar@cmu.edu
Abstract
DevOps is a set of practices in software engineering that is
in high demand by industry. It is a dynamic eld which con-
stantly adds new methods and tools. Teaching DevOps pre-
pares today’s computer science students for best-practices in
a working environment but challenges university lecturers
to provide central concepts while staying up-to-date with
current trends. In this paper we report and reect on our
experiences teaching DevOps at two universities (in the USA
and Germany) in an inverted classroom format. We describe
how we set-up the courses, provide a brief analysis of data
we collected, and share our lessons learned.
CCS Concepts: •Software and its engineering →Agile
software development.
Keywords:
DevOps, inverted classroom, software engineer-
ing
ACM Reference Format:
Richard Hobeck, Ingo Weber, Len Bass, and Hasan Yasar. 2021.
Teaching DevOps: A Tale of Two Universities. In Proceedings of the
2021 ACM SIGPLAN International SPLASH-E Symposium (SPLASH-E
’21), October 20, 2021, Chicago, IL, USA. ACM, New York, NY, USA,
6pages. hps://doi.org/10.1145/3484272.3484962
1 Introduction
It was the best of classes, it was the worst of classes.
1
DevOps
has become a widely established set of practices in software
development. A central goal of DevOps is to accelerate the
time-to-market of software features [
2
]. Including DevOps
as a subject in IT-related university studies can provide stu-
dents with the basics to work on agile software engineering
1Apologies to Charles Dickens for corrupting “The Tale of Two Cities”.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not
made or distributed for prot or commercial advantage and that copies bear
this notice and the full citation on the rst page. Copyrights for components
of this work owned by others than ACM must be honored. Abstracting with
credit is permitted. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specic permission and/or a fee. Request
permissions from permissions@acm.org.
SPLASH-E ’21, October 20, 2021, Chicago, IL, USA
©2021 Association for Computing Machinery.
ACM ISBN 978-1-4503-9089-7/21/10. . . $15.00
hps://doi.org/10.1145/3484272.3484962
projects with fast release cycles, as well as promote a broader
adoption of DevOps in practice.
A teaching method that benets from the wide availability
of digital technology in education is the inverted classroom:
students familiarize themselves with the learning content
outside the lecture (e.g., by means of videos) and reproduce
and apply their knowledge to problems posed in synchronous
classroom lectures [4].
The authors of this paper synchronized the content of their
DevOps classes and taught them in an inverted classroom
format. The classes were given at two dierent universities:
Carnegie Mellon University (CMU) in Pittsburgh, USA and
Technische Universität Berlin (TUB) in Germany.
A number of recent publications touch on DevOps edu-
cation. A framework for teaching DevOps in academia was
proposed by [
9
]. With a focus on lecture content, DevOps
teaching experience in an academic environment was de-
scribed for a French university [
3
] and for an American uni-
versity [
8
]. While these publications oer interesting insights
to teaching DevOps in two dierent academic systems, no di-
rect comparison between the system-related experiences was
conducted – a perspective that we intend to share. Teaching
reports can also be found from an industrial setting [
11
]. Ex-
periences in academic and industrial contexts were compared
by [
5
]. Although [
8
] mentions using an inverted classroom
format, the teaching method is not extensively described or
reected on.
In this paper we describe and compare the teaching prac-
tices of the two classes at CMU and TUB, and share our
experiences with inverted classroom as a pedagogic practice
in software engineering subjects.
The model of learning by Hughes, Toohey, & Hatherley [
7
]
comprises ve phases: “be introduced to the topic; get to
know it; try it out; get feedback; apply it.” In the model, clas-
sic lectures and, in our context of inverted classroom, video
lectures are useful for the rst two phases (mostly 1), tutorials
for phases 2-4 (mostly 2), and assignments for phases 3, 4, and
5. According to the Experiential Learning Theory of Kolb [
10
],
“Knowledge results from the combinations of grasping and
transforming the experience.” Therein, the grasping expe-
rience includes two modes: abstract conceptualization and
concrete experience, which are respectively addressed by
the video lectures and the assignments. The transforming ex-
perience also comprises two modes: active experimentation
SPLASH-E ’21, October 20, 2021, Chicago, IL, USA Hobeck, et al.
Approve for deployment
Dev
Deploy
Operate
Build
Release
Monitor &
Analyze
Test
5. Release
4. Test
3. Build
2. Dev
6. Deploy
7. Operate
8. Monitor &
Analyze
1. Design
Create an executable
artifact
Ensure high test
coverage & automate
tests as much as
possible
Design architecture to support
other activities
Perform normal
development activities
Create scripts for other
activities
Move into production
environment
Execute system and gather
measurements about its
operation
Display measurements taken
during operation
& analyze the data
Figure 1. DevOps processes
and reective observation. The former is addressed by our
non-prescriptive assignments, which specify the goal but
not the path, and require a degree of active experimentation.
The reective observation is addressed through the in-depth
discussions with the class, which exceed the video lecture
content in depth.
In the following, we rst give an overview on the course
contents, structures, and teaching methods. Subsequently,
a brief analysis of time sheets compares how much time
students at the two universities spent on assignments in
Section 3. Then we report on our lessons learned in Section 4.
Finally, we summarize and reect in Section 5.
2 Teaching modalities
DevOps comprises a wide eld in computing and information
systems, integrating organizational,cultural as well as tech-
nical aspects. An overview of DevOps processes is shown
in Figure 1. We teach at engineering departments at two
universities and thus focused largely on the technical facets
of DevOps in our courses. That is also reected in the tar-
geted learning outcomes of the course. On the one hand,
students will be familiar with technical concepts such as
microservice architecture, deployment pipelines or infras-
tructure as code (see the course content for CMU and TUB
in Table 1). On the other hand, we oer practical assign-
ments with industry-standard software tools such as Docker
2
,
Kubernetes
3
,Jenkins
4
, or Logstash
5
. The content taught is
aligned with the learning outcomes, and so are the forms of
assessment, including formative (quizzes, assignments) and
summative (exams / tests) [6].
However, the two courses are oered at dierent univer-
sities and are taught in conformance to the specics of the
educational system they are embedded in, which will be
covered in the next two subsections.
2https://www.docker.com/
3https://kubernetes.io/
4https://www.jenkins.io/
5https://www.elastic.co/de/logstash
Course Content CMU TUB DP
Introduction to DevOps R R All
Infrastructure as code R O 6,7,8
Conguration management R O 2,3
Virtual machines R R 1,2
Containers R R 1,2,3,6,7
Networking R O 1,2,3
The cloud R O 1,2,3
Container management R R 1,2,3,6,7
Infrastructure security R R 1,4,5,6,7
Deployment pipeline R R 6
Microservice architecture R R 1,3
Service meshes R R 1,3
Postproduction R R 7,8
Disaster recovery R R 7,8
Secure development R O 1,2
Domain specic DevOps R O All
Distributed system archt. R O 1,2
Case studies R R All
Table 1.
Comparison of course contents at CMU and TUB
(R: required content, O: optional content), and relation to
DevOps processes (DP) from Figure 1
2.1 CMU Course
The CMU DevOps course is divided into two portions –
equal in assessment weight. These two portions are theory
and practice. The theory is taught using a form of inverted
classroom. The practice is taught through assignments using
various tools important in the DevOps world. The theory
is divided into 25-30 video lectures that are 20-30 minutes
long. The lecture videos as well as the lecture slides are pub-
licly available on the platforms PresentationTube
6
, YouTube
7
,
Slideshare
8
, and GitHub
9
. The number of video lectures of-
fered per semester at CMU depends on holidays and the
university schedule. Prior to class a student will:
•
Watch the video for that day that was recorded by the
lecturer at CMU
•
Read the assigned reading – mostly from the text-
books [1,2], but also from other sources.
•Post one question for in class discussion
During class, 15 minutes are allocated for an automatically
graded quiz over the previous class’ video content, discus-
sions, and readings. This is followed by a discussion of the
questions in the quiz, usually lasting another 10-15 minutes.
There will then be a discussion based on the video, readings,
and posted questions. The length of the discussion is based
on class size. It may take up the remaining time. If it does
6https://presentationtube.com/users/prole/publicprole.php?m=lbass
7https://www.youtube.com/user/lenjbass
8https://www.slideshare.net/lenbass/presentations
9https://github.com/cmudevops/course-materials
Teaching DevOps: A Tale of Two Universities SPLASH-E ’21, October 20, 2021, Chicago, IL, USA
not, there is a breakout session with 5-6 students per break-
out group over some topic. It may involve answering some
questions or it may involve developing a context diagram
for some piece of software relevant to an assignment or the
lecture topics.
Outside of class the students will perform the assignments,
individually. There are seven to ten assignments per semes-
ter. Each assignment involves installing a tool and using
that tool to perform some simple task. Students are asked to
hand in step-by-step instructions that explain their approach,
screenshots, and a textual response to a question posed over
the assignment. We further ask students to provide simple
time sheets, where they recorded how much time they spent
on the assignments. Students use the internet to educate
themselves about the use of the tool. Questions about the as-
signment are asked and answered via e-mail or in laboratory
sessions.
2.2 TUB Course
At TUB, the course content was largely designed as a subset
of the one taught at CMU. However, in contrast to CMU,
which included two time slots of 1.5 hours per week, the
TUB course is block-structured: each block is 3.5-4 hours in
length (including breaks), and takes place every two weeks.
In the rst block, the lecturer presents an overview of the
core concepts of DevOps. Subsequent blocks start with a
quiz of 10-20 minutes each, followed by discussions about
the video contents. The video contents are the same as at
CMU. Mostly this is done with discussion questions, which –
in contrast to CMU – were prepared by the lecturer ahead of
time (and not by the students). During the discussion, notes
are taken by the lecturer, while the screen is shared with the
class. When the initial student answers are not fully on point,
the notes are rened through follow-up discussion. To this
end, we use a note-taking tablet, on which the lecturer writes
and draws by hand. PDFs of the resulting notes are later
shared with the class. In one to two blocks, guest lectures
are given by industry professionals.
At TUB, students do not select their courses before the se-
mester, but at the start of it. In TUB’s moodle installation
10
,
interested students self-enroll for courses that meet their
interest; for DevOps, the rst oering registered over 220
such enrollments, though only 25 spots are oered (to en-
able the kind of active participation we aim for). Thus, we
implemented the following selection procedure. First, a kick-
o meeting was scheduled where the lecturer explained the
course structure, content (a 15-minute presentation), grading
components, and expectations. Students then could opt to ap-
ply for the 25 spots, and the chair oering the course selects
25 students on the basis of formal criteria and randomness,
as per the rules of the university. This student selection in-
troduces a dierence to CMU’s set of participating students,
10https://isis.tu-berlin.de/
since TUB students have more information but also need to
make an eort to become a participant of the course.
The course at TUB also includes a hands-on part that
consists of four to ve assignments. The assignments are a
subset of the assignments oered at CMU (except Terraform)
with the same instructions and deliverables. They are due
every two weeks and are accompanied by Q&A-sessions
and short overview tutorials for the students, but the largest
portion of necessary knowledge to complete the assignments
has to be self-taught. Additionally, we responded to student’s
questions in moodle and via e-mail.
3 A brief analysis of time sheet data
The assignments oered to the students of both universities,
CMU and TUB, were drawn from the same pool of assign-
ments. The instructions were kept the same in every semester
(Jenkins remained xed after summer 2019) slight changes
were made to supportive material, as the tools changed over
time. The students’ task in each assignment comprised solv-
ing small software challenges with well-established DevOps
tools. For all assignments, the students were asked to doc-
ument the time it took them to complete the tasks. The
assignments were related to the following software tools or
techniques: virtual machine management, SSH, Chef, EC2,
Chef Vault, Vagrant, Jenkins, Docker, Nagios, Kubernetes,
Ansible, Ansible Vault, Wire Shark, Terraform, and Logstash.
The times were documented in the academic terms from fall
2017 to summer 2021 at CMU and summer 2020 to summer
2021 at TUB (see Table 2). Although this paper is primarily
an experience report, we analyzed the assignment times to
get additional insights for the comparison of the student
groups of both universities.
Figure 2shows a comparison between the median times
recorded from CMU and TUB students, grouped by assign-
ment once they were stable. Note that not all assignments
were oered in every semester or each university. The gure
shows that assignments that were oered at an early stage
of the semester (e.g., SSH, Virtual machine, Vagrant, Docker)
took students less time to solve than assignments from a
later stage of the semester (e.g., Ansible, Jenkins, Logstash).
Looking at the gure, a visual comparison between the times
recorded for tools that both universities have in common sug-
gests that TUB students were slightly faster solving Docker,
Kubernetes and Logstash assignments, but took signicantly
less time solving the Jenkins assignment. Using the Kol-
mogorov–Smirnov test on the data from each of the four
assignments, we received p-values ranging from 0.39-0.94
which strongly indicates the null-hypothesis (samples drawn
from populations with the same distribution) can be accepted,
so that we assume the data sets are comparable. The Mood’s
median test provided p-values of 0.63 (Docker), 0.64 (Ku-
bernetes), 0.02 (Jenkins), and 1.0 (Logstash), which suggests
SPLASH-E ’21, October 20, 2021, Chicago, IL, USA Hobeck, et al.
Assignments 2017 ’18 ’19 ’20 ’21 DP
VM mngnt. C C C 1,2
SSH C C C C C 1,2,3
Chef C C 6
EC2 C C 6,7
Chef Vault C C 6,7
Vagrant C C C C All
Jenkins C C C C, T C, T 3,4,5
Docker C C C C, T C, T 1,2,3,6,7
Nagios C C C C 8
Kubernetes C C C, T C, T 6,7
Ansible C C C 6
Ansible Vault C C C 6,7
Wire Shark C 1,2,3
Terraform T 6,7
Istio C 6,7
Logstash C C C, T C, T 8
Table 2.
Assignments matched with the year they were of-
fered at CMU (C) and TUB (T), and relation to DevOps pro-
cesses (DP) from Figure 1
Ansible
Ansible Vault
Chef
Chef Vault
Docker
EC2
Jenkins
Kubernetes
Logstash
Nagios
SSH
Terraform
Vagrant
Virtual machine
Wire Shark
Assignment
0
200
400
600
800
Median time in min
University
CMU
TUB
Figure 2.
Median time over all data points from all semesters,
grouped by assignment
that students of both universities were similarly fast solv-
ing Docker, Kubernetes and Logstash assignments, but TUB
students were faster solving the Jenkins assignment. When
looking at assignments individually, we can also observe that
Vagrant, Nagios, Logstash saw a time increase over the years
(not shown in the gure). Contrary to that trend, for SSH,
Docker, and Kubernetes assignments students expended a
stable or slightly decreasing amount of time over the years.
Threats to Validity.
The above analysis is subject to
threats to validity. First, self-reported times are not partic-
ularly reliable. The representatives of the data can not be
guaranteed, among others for two reasons. First, at TUB, we
made clear in the kicko meeting that the course will likely
be perceived as challenging, so some students might have
not applied for participation. Second, since participation in
our study was of course optional, not all students partici-
pated, and hence those did not hand in their time sheets. The
lessons reported in Section 4 are subjective, and may or may
not be replaceable in other contexts.
4 Lessons learned and experiences
As instructors of the courses, we are confronted with a chal-
lenge: DevOps is a quickly shifting eld and particularly its
heavy dependence on automation tools gives the eld con-
stant momentum. While some of the tools are established by
now, new solutions emerge frequently and inuence numer-
ous traditional practices immediately. Our teaching goals
for the course are thus divided into two sub-goals which are
reected in the lecture and assignment content. 1) In the lec-
ture we focused on teaching underlying, lasting concepts of
software engineering, including but not limited to threshold
concepts [
12
], and core concepts of DevOps in particular,
and we chose inverted classroom questions that we thought
would help deepen students’ understanding of the subject.
2) In the assignments we focused on exposing students to
essential techniques and more recent trends and tools (e.g.,
Terraform: v1.0.0 release, 8 June 2021
11
, assignment started
23 June 2021).
Lecture.
The content and inverted classroom format of
the lecture are well received by the students – student evalua-
tions of the course at both universities included the sentence
”best I have ever taken/had”. This was also reected in the
overall rating, which was well above average. However, some
students saw the repetition of content from the video lec-
tures through discussions in the classroom as repetitive and
little helpful. Additionally, at German universities partici-
pation is not supposed to be mandatory, which inherently
conicts with the inverted classroom style. In-class discus-
sion is arguably essential to foster deeper understanding in
inverted classroom settings. At TUB, we mitigated the issue
by oering a small percentage of the points for the whole
course for in-class participation, with an easy-to-meet bar
for achieving full points in terms of quality of answers or
comments from the students.
While many discussion questions focused on deepening
the content from the video lectures, some discussion ques-
tions were targeted at applying the knowledge and asked
about implications of certain statements. For instance, in one
lecture video, the Amazon design rules
12
were presented;
the discussion question then asked about the implication of
designing services from the ground up to be externalizable.
After some deliberation and discussion, students mentioned
11
https://github.com/hashicorp/terraform/releases/tag/v1.0.0, accessed
2021-07-16
12https://presentationtube.com/watch/?v=vZRsbfnIeqV
Teaching DevOps: A Tale of Two Universities SPLASH-E ’21, October 20, 2021, Chicago, IL, USA
among others, that API design had to play a bigger role, and
security considerations had to be implemented from the start
of the development process.
When the COVID pandemic started in 2020, the inverted
classroom style facilitated transitioning to fully remote teach-
ing. Since the lectures were already recorded on video, the
pre-class activities were unchanged. In-class activites, how-
ever, changed signicantly. On the technical side, some stu-
dents do not have cameras, or sometimes the technology
fails, which posed interruptions to the course.
At CMU, the in-person discussion also requires the student
to pay attention at all times because they might be called on
to continue a line of questioning. Students’ body language
reveals to the lecturer how much they are paying attention.
The ones that were not paying attention became more likely
to be the next called on. With remote teaching, the ability
to measure engagement is much reduced. Many times, the
response of a student to a question is "could you repeat the
question". This indicates the students answering in this way
were not paying attention.
During the in-class lectures at TUB we observed that more
lively discussions and a more productive atmosphere devel-
oped when students did not feel pressured by our questions
and were able to contribute only when they felt they actually
had points to contribute. Still, we wanted to provide equal
chances to address the class to all students, while ensuring
that all students also participate actively. To achieve this,
we asked students to raise their hand (virtually in the video
conferencing tool) if they wanted to contribute and invited
them to speak when it was their turn – while keeping track
of the number of inputs per student. If the number of contri-
butions became imbalanced, we counter-acted by skipping
students’ raised hands or announcing that we expect contri-
butions from certain students and calling on them shortly
after (usually from a raised hand).
In addition to the usual inverted classroom blocks, we also
had guest lectures at TUB. During those were able to observe
that the discussions were more stimulating when the lecture
content was provided as a video ahead of the time and the
guest had a conversation with the students in an inverted
format – even if the guest’s content was watched only briey
right before the inverted classroom started.
Assignments.
We asked the students to record how much
time they spend on each assignment. This allows us to an-
nounce expected time expenditure to students, simplifying
their multi-course scheduling challenges.
A particularity of the assignments was that they were
vaguely formulated and usually just stated a starting point
for the assignment and the goal (e.g., deploying a sample
application in a Docker container). We decided to use vague
wording purposefully, to give students the chance to try out
the tools themselves, without forcing them into a solution
path. At TUB, where clearly dened student assignments are
more common, we took two lessons away from that: 1) vague
wording results in high variance in the formal quality of the
submissions, and 2) it is important to manage expectations
accordingly. Students were typically more used to clearly
dened solution spaces and complained about the additional
freedom, unless we clearly stated that to be purposeful.
Post class experience.
From guest lectures and feedback
we received from students after they found jobs, we learned
that the lecture content is well aligned with industrial soft-
ware engineering practice.
At CMU, multiple students have reported after working
in their jobs for a while that they found the DevOps course
to have been of great value. Some students moved directly
into a DevOps role or DevOps trainee role. At TUB, many
students had jobs parallel to their studies and gave similar
feedback.
Students also reported that their experiences in job inter-
views were dierent from those of their colleagues who did
not take the course. The standard industrial interview basi-
cally questions the student on their algorithmic knowledge.
Some of our former students reported that they were sent on
an interview path that explored their DevOps knowledge.
5 Summary and Reection
In this paper, we presented our experiences with teaching
DevOps at two universities, CMU and TUB. The content of
the course is summarized in Table 1, including a mapping
to the DevOps processes depicted in Figure 1. The courses
were taught in an inverted classroom format, with lecture
videos and in-depth discussions. We found that the inverted
format worked well in a remote setting. Students valued the
style of teaching and content, and some employers valued
the resulting skill sets.
The lecture content was supplemented with assignments,
listed in Table 2, and we analyzed time sheets from the stu-
dents, i.e., how much time they spent on which assignment.
This time sheet analysis showed no signicant dierences
between the students at CMU and TUB, for all but one of
the assignments. When providing assignments with a broad
solution space, we recommend to communicate that clearly
in advance to set expectations accordingly. Designing as-
signments based on DevOps tools turned out to contribute
to learning success and helped students acquire relevant
practical skills.
Given the open accessibility of the video content, other
universities could oer similar modules with relative ease.
However, teaching DevOps poses additional tasks for the
instructors since the eld and tool landscape change rapidly.
This can be observed from the second table: while the con-
cepts and lecture contents on the high level stayed the same
over the years (albeit some details changed), in Table 2 a drift
can clearly be observed for the assignments over the years.
SPLASH-E ’21, October 20, 2021, Chicago, IL, USA Hobeck, et al.
References
[1]
Len Bass and John Klein. 2019. Deployment and Operations for Software
Engineers. Amazon.
[2]
Len Bass, Ingo Weber, and Liming Zhu. 2015. DevOps:
A Software Architect’s Perspective. Addison-Wesley Profes-
sional. hps://www.amazon.com/DevOps-Soware-Architects-
Perspective-Engineering/dp/0134049845
[3]
Benjamin Benni, Philippe Collet, Guilhem Molines, Sébastien Mosser,
and Anne-Marie Pinna-Déry. 2019. Teaching DevOps at the Graduate
Level. In Software Engineering Aspects of Continuous Development and
New Paradigms of Software Production and Deployment, Jean-Michel
Bruel, Manuel Mazzara, and Bertrand Meyer (Eds.). Springer Interna-
tional Publishing, Cham, 60–72.
[4]
J.L. Bishop and Matthew Verleger. 2013. The ipped classroom: A sur-
vey of the research. ASEE Annual Conference and Exposition, Conference
Proceedings (01 2013).
[5]
Evgeny Bobrov, Antonio Bucchiarone, Alfredo Capozucca, Nicolas
Guel, Manuel Mazzara, and Sergey Masyagin. 2020. Teaching De-
vOps in Academia and Industry: Reections and Vision. In Software
Engineering Aspects of Continuous Development and New Paradigms
of Software Production and Deployment, Jean-Michel Bruel, Manuel
Mazzara, and Bertrand Meyer (Eds.). Springer International Publishing,
Cham, 1–14.
[6]
John T. Hastings, Benjamin Samuel Bloom, George F. Madaus, and
J. Thomas Hastings. 1971. Handbook on formative and summative
evaluation of student learning. MacGraw-Hill, New York.
[7]
Chris Hughes, Sue Toohey, and Sue Hatherly. 1992. Developing
learning-centred trainers and tutors, Studies in Continuing Educa-
tion. Studies in Continuing Education 14, 1 (1992), 14–27. hps:
//doi.org/10.1080/0158037920140102
[8]
Rachel A. Kaczka Jennings and Gerald Gannod. 2019. DevOps - Prepar-
ing Students for Professional Practice. In 2019 IEEE Frontiers in Edu-
cation Conference (FIE). 1–5. hps://doi.org/10.1109/FIE43999.2019.
9028598
[9]
Christopher Jones. 2019. A Proposal for Integrating DevOps into
Software Engineering Curricula. In Software Engineering Aspects of
Continuous Development and New Paradigms of Software Production
and Deployment, Jean-Michel Bruel, Manuel Mazzara, and Bertrand
Meyer (Eds.). Springer International Publishing, Cham, 33–47.
[10]
David Kolb. 1984. Experiential Learning: Experience As The Source Of
Learning And Development. Prentice-Hall.
[11]
Manuel Mazzara, Alexandr Naumchev, Larisa Sana, Alberto Sillitti,
and Konstantin Urysov. 2019. Teaching DevOps in Corporate Environ-
ments. In Software Engineering Aspects of Continuous Development and
New Paradigms of Software Production and Deployment, Jean-Michel
Bruel, Manuel Mazzara, and Bertrand Meyer (Eds.). Springer Interna-
tional Publishing, Cham, 100–111.
[12]
J. H. F. Meyer, R. Land, and C. Rust. 2003. Threshold concepts and
troublesome knowledge: linkages to ways of thinking and practising
within the disciplines. In International Symposium on Improving Student
Learning. 412–424.
