Conference PaperPDF Available

Teaching DevOps: A Tale of Two Universities

Conference Paper

Teaching DevOps: A Tale of Two Universities

Abstract

DevOps is a set of practices in software engineering that is in high demand by industry. It is a dynamic field which constantly adds new methods and tools. Teaching DevOps prepares 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 reflect 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.
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 reect 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. hps://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 prot 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 specic 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
hps://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 benets 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 dierent 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 oer interesting insights
to teaching DevOps in two dierent 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
reected 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 reective 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 reective 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 reect 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 reected 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 oer 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 oered at dierent univer-
sities and are taught in conformance to the specics 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
Conguration 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 specic 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/prole/publicprole.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 rened 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 oering registered over 220
such enrollments, though only 25 spots are oered (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 oering 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 dierence to CMU’s set of participating students,
10https://isis.tu-berlin.de/
since TUB students have more information but also need to
make an eort 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 oered 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 oered 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 oered in every semester or each university. The gure
shows that assignments that were oered 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 signicantly
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 inuence numer-
ous traditional practices immediately. Our teaching goals
for the course are thus divided into two sub-goals which are
reected 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 reected 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
conicts 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 oering 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 signicantly. 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 briey
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 dened 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
dened 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 dierent 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 Reection
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 signicant dierences
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 oer 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. hps://www.amazon.com/DevOps-Soware-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: Reections 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. hps:
//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. hps://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 Sana, 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.
... In recent years some institutions have started to include DevOps as part of their programs. In some cases specific DevOps courses have been created [8]- [10]. In some other cases DevOps topics have been added to existing Software Engineering courses as the case described here. ...
... The Rest API is run in Heroku using its container support and the free PostgreSql database plugin. The Telegram bot is deployed to a Kubernetes cluster running on the Digital Ocean cloud provider 8 . ...
Conference Paper
DevOps is one of the mainstream topics in the software industry nowadays. Because of this, in recent years, some universities have started to include DevOps related content in their programs. In some cases, specific DevOps courses were created while in other cases DevOps topics were included in existing ones. This article describes an experience of including DevOps topics in a Software Engineering advanced course. Details of the practices and tools covered are provided along with explanations of the teaching approach and the cloud services used to deliver the course.
... Moreover, we noticed that Environment Setup is a recurrent challenge, but only a few recommendations were provided by the interviewed educators to address this challenge. 14 15 14 10 12 8 10 strategies in course execution 12 The following subsections present results of the analysis grouped by theme. In particular, we show how the identified challenges and recommendations were derived from specific situations mentioned during the interviews. ...
... Hobeck et al. 's study [10] reports on the experience of teaching DevOps involving two universities (in the US and Germany), implementing a flipped classroom format. Similar to our work, their study discusses challenges from the instructors and students, like "constant change of DevOps tools". ...
Preprint
Full-text available
Over the last years, the software industry has adopted several DevOps technologies related to practices such as continuous integration and continuous delivery. The high demand for DevOps practitioners requires non-trivial adjustments in traditional software engineering courses and educational methodologies. This work presents an interview study with 14 DevOps educators from different universities and countries, aiming to identify the main challenges and recommendations for DevOps teaching. Our study identified 83 challenges, 185 recommendations, and several association links and conflicts between them. Our findings can help educators plan, execute and evaluate DevOps courses. They also highlight several opportunities for researchers to propose new methods and tools for teaching DevOps.
Chapter
In this education paper we outline a course and exercise design aimed at teaching students knowledge and skills in refactoring (“strangling”) a monolith architecture into a microservice equivalent using a cross team DevOps process. The core aim of our proposed exercise design is that students are engaged in a realistic DevOps process by working in teams on team specific microservices, negotiating interfaces with other teams while ensuring all microservices will interact seamlessly to provide correct system behavior. Our main contribution is to outline the challenges faced when designing such an exercise, our proposals for solving them, the exercise design itself, guidelines for exercise design, as well as present experiences from two courses using this approach.
Conference Paper
Over the last years, the software industry has adopted several Dev-Ops technologies related to practices such as continuous integration and continuous delivery. The high demand for DevOps practitioners requires non-trivial adjustments in traditional software engineering courses and educational methodologies. This work presents an interview study with 14 DevOps educators from different universities and countries, aiming to identify the main challenges and recommendations for DevOps teaching. Our study identified 83 challenges, 185 recommendations, and several association links and conflicts between them. Our findings can help educators plan, execute and evaluate DevOps courses. They also highlight several opportunities for researchers to propose new methods and tools for teaching DevOps.
Chapter
Full-text available
The new century brought us a kind of renaissance in software development methods. The advent of the Agile manifesto has led to greater appreciation of methodologies aimed at producing valuable software through continuous incremental cycles. More recently, a new set of practices enclosed under the term DevOps has appeared to attain manifesto’s objectives in more efficient manner. The software development community has already noticed the benefits brought by DevOps. Thus, the necessity of education in the field becomes more and more important, both from the technical and organisational point of view. This paper describes parallel experiences of teaching both undergraduate and graduate students at the university, and junior professional developers in industry, compares the two approaches and sums up the lessons learnt. A vision driven by the DevOps practices aimed at implementing a shift in the Software Engineering Higher Education curricula to takeover its current limitations is also reported at the end of the paper.
Chapter
Full-text available
The material uploaded consists of the preface, Intro to Part 1, Chapter 1 Virtualization, and Intro to Part 2 for the book Deployment and Operations for Software Engineers. Virtualization refers both to virtualizing the hardware (Virtual Machines) and virtualizaing the operating system (containers). The chapter provides the material on virtualization that every software engineer or CS graduate should know
Article
Full-text available
Recent advances in technology and in ideology have unlocked entirely new directions for education research. Mounting pressure from increasing tuition costs and free, online course offerings is opening discussion and catalyzing change in the physical classroom. The flipped classroom is at the center of this discussion. The flipped classroom is a new pedagogical method, which employs asynchronous video lectures and practice problems as homework, and active, group-based problem solving activities in the classroom. It represents a unique combination of learning theories once thought to be incompatible-active, problem-based learning activities founded upon a constructivist ideology and instructional lectures derived from direct instruction methods founded upon behaviorist principles. This paper provides a comprehensive survey of prior and ongoing research of the flipped classroom. Studies are characterized on several dimensions. Among others, these include the type of in-class and out-of-class activities, the measures used to evaluate the study, and methodological characteristics for each study. Results of this survey show that most studies conducted to date explore student perceptions and use single-group study designs. Reports of student perceptions of the flipped classroom are somewhat mixed, but are generally positive overall. Students tend to prefer in-person lectures to video lectures, but prefer interactive classroom activities over lectures. Anecdotal evidence suggests that student learning is improved for the flipped compared to traditional classroom. However, there is very little work investigating student learning outcomes objectively. We recommend for future work studies investigating of objective learning outcomes using controlled experimental or quasi-experimental designs. We also recommend that researchers carefully consider the theoretical framework used to guide the design of in-class activities.
Chapter
The “2017 State of DevOps Report” asserts that 27% of its respondents work on devops teams, an increase of almost 23% from 2016 and almost 69% from the 2015. Devops practices are intended to improve an organization’s software development throughput by reducing the cycle time needed for a software change to reach its users. Although the skills needed for effective devops are in demand, it is challenging to integrate it into a academic curriculum for several reasons. First, software development curricula often only take students through the delivery stage of software development and do not spend meaningful time on operational activities, making it difficult to recruit faculty with the requisite IT operations experience. Second, many of the applications and their environments that can most benefit from devops are extremely complex, making it difficult to provide an appropriate learning environment. Third, many requirements for successful devops are not technical but instead emphasize the human and organizational aspects of our craft. Fourth, for many students, the problems addressed by devops are abstract. In this paper we look at these challenges in more detail and review one proposal for integrating devops into existing curricula in light of current devops maturity models, disciplines, and industry trends.
Chapter
The massive evolution of IT development towards new Web architectures, from service-oriented to micro-services, clouds and containers, call for changes in the way software is developed, deployed and maintained.
Chapter
This paper describes our experience of training a team of developers of an East-European phone service provider. The training experience was structured in two sessions of two days each conducted in different weeks with a gap of about fifteen days. The first session was dedicated to the Continuous Integration Delivery Pipeline, and the second on Agile methods. We summarize the activity, its preparation and delivery and draw some conclusions out of it on our mistakes and how future session should be addressed.