Development and Operation of Distributed Applications

The world of Software Engineering has been revolutionized in the last decade. Instead of releasing software updates yearly, companies can now release multiple times per week, sometimes even per day, to their customers. This allows quick reactions to market demands, software failures, and it is crucial for increasing the business value of software. These improvements come largely from new DevOps practices and from advances in release engineering. In this course, we will explore the underlying key techniques and technologies that build the foundation for the modern development and operation of distributed applications. 

The main target audience of this course are software engineers who want to learn how to systematically release reusable software and make their applications scalable in an orchestrated environment. Together, we will build a release pipeline for a small toy project and go on a journey that starts at continuous integration and then moves on to continuous delivery, continuous deployment, and continuous experimentation. We will discuss the theory and the current research on various related subjects like containerization, testing, or monitoring and will put the learned theory into practice. 

Important: Make sure to register for a group in Brightspace AT THE LATEST during the first lecture. 

Important: The course will introduce several state-of-the-art tools. While in theory all major operating systems should be supported, experience has shown that Windows users will face challenges. To reduce the friction points, we strongly recommend affected students to either dual-boot a Linux system or to boot a Linux live system via USB.

Formative Assessment

• You can check your individual learning progress through weekly rubrics

  • You will receive feedback from other groups as a neutral outsider

  • You can check your own progress via self-assessment

• Joint Q&A sessions will discuss common points of the peer feedback and concrete questions

Individual Knock-Out Elements

The course enforces several criteria to protect the active members of a team. Students not reaching the following criteria will fail the course:

• Actively participating in the team process and contributing to all team deadlines and deliverables

• Visible and meaningful contributions in W2-W9 that add code, configs, or requested documentation. Missing contributions in one week can be compensated once(!) through contributions in W10.

• Constructive and timely participation in peer reviews for all assignments (one for another team and one for your own)

• Availability of team results for grading (repositories, report, artifacts)

Students who fail any of these criteria must repair their lack of participation through an additional assignment after course end to qualify for the summative assessment. This repair is available for students who have meaningfully contributed to their team efforts in at least 4 weeks before failing. It involves a programming task, a review task, and will be assessed in an oral exam. The final grade of this repair is capped at 6.0.

Summative Assessment

To receive a grade for the course, students need to pass the final presentation/oral exam.

• Presentation & Oral Examination (Pass/Fail, repairable)

Students who are unable to explain lecture contents or defend specific aspects of the team project in the oral examination will fail the oral exam, but have a repair opportunity in a second oral examination.

The final grade for students who pass the exam is then determined through the following partial grades:

• Development (30%)

• Operation (40%)

• Experimentation (30%)

Partial grades are always rounded to .1 and the final grade to .5. All partial grades that are >=4.0 and <6.0 can be repaired by resubmitting an improved version, but the grade of each repair is capped at 6.0. To pass the course, each partial grade has to be at least a 5.0 and the final grade has to be a 6.0.

We may choose to assess students individually if we become aware of large performance differences in a team. We will then base our assessment on the interaction traces that we find in the team repositories (e.g., contributions to the deliverables) and might also request a detailed list of contributions from each team member.

Please Note

• All assignment deadlines throughout the course are fixed, we do not accept late submissions. Late submissions in systems that do not enforce due dates will be treated as not submitted (e.g., Brightspace, Buddycheck, Peer).

• Failing to submit a deliverable cannot be repaired.

• Due to the teamwork in the course, there is NO resit opportunity.

• Partial grades are not carried over to the next academic year.

Disclaimer: information may change depending on unforeseen circumstances or measures (see: TER Art 29, sub 4)