Course Structure — SDDO · IE University BCSAI 2025

Module 1 · Sessions 1–2

Foundations & the Software Development Life Cycle

Sets the frame for the whole course: what software development is as a discipline, a brief history up to the cloud-and-AI era, the first definition of DevOps, and the phased life cycle every project moves through whether or not anyone names it.

Learning outcomes

Place programming inside the larger SDLC framework.
Distinguish the major SDLC models and when each is appropriate.
Name the roles and responsibilities that recur across every phase.

Session 1 · Live

Introduction & overview of Software Development and DevOps

Objective: orient students to the course shape and the discipline, and plant the first definition of DevOps.

Academic course structure — how the 35 sessions, assignments, and exams fit together (the map this page draws). The hidden message: the course mirrors the SDLC itself — you plan, build, test, ship, and operate one app across the semester.
SDLC introduction — the idea that building software follows describable, repeatable phases rather than ad-hoc effort. Naming the phases is what lets a team divide labour, estimate, and know what "done" means at each step.
Brief software history — from early monoliths and mainframes through client–server and the web to cloud computing and the AI era. Each era shifted the bottleneck (compute → networking → release speed → reliability), and DevOps is the response to the release-speed bottleneck.
DevOps introduction — the first framing of DevOps as the union of development and operations under shared ownership. Historically these were separate teams with opposed incentives (Dev wanted change, Ops wanted stability); DevOps aligns them around one goal: reliable, frequent delivery.

Core concept · DevOpsA culture and set of practices that merge software development (Dev) and IT operations (Ops) to shorten the delivery cycle and ship reliably and continuously — built on automation, fast feedback, and shared responsibility for what runs in production.

Common pitfallTreating DevOps as a job title or a tool you "install". It is an operating model: hiring a "DevOps engineer" to do all the ops while developers stay hands-off recreates the very wall DevOps exists to remove.

Key ideaDevOps is a culture before it is a toolset. The tools only matter once development and operations stop being separate teams that throw work over a wall.

TakeawayThe course is one long worked example: a single app, planned in week 1, taken all the way to operated-in-production by week 35.

Session 2 · Live

Software Development Life Cycle (SDLC)

Objective: study each SDLC phase, compare the models, and assign Individual Assignment 1.

Each phase of the SDLC — requirements, design, implementation, testing, deployment, maintenance — each producing a concrete artifact (a spec, a design doc, code, a test report, a release, a changelog). Knowing the artifact tells you when a phase is genuinely finished.
SDLC models — Waterfall (sequential, each phase signed off before the next), the V-model (each build phase paired with a test phase), iterative and spiral (repeat with growing scope, spiral adding risk analysis), and Agile (short cycles, continuous re-planning). The deciding factor is the cost and likelihood of change: stable requirements favour predictive models, volatile ones favour adaptive.
Roles & responsibilities — analyst (requirements), architect (design), developer (build), QA (test), ops (run) — though DevOps deliberately blurs the developer/ops split so one team owns the feature end to end.
Individual Assignment 1 introduced — build a minimal application; the seed of the project carried through the course and improved with DevOps practices in Assignment 2.

Core concept · SDLCA structured sequence of phases for producing software. Predictive models (Waterfall, V) plan everything up front; adaptive models (iterative, Agile) embrace change by delivering in cycles and re-planning each time.

Common pitfallEquating Waterfall with "bad" and Agile with "good". Waterfall is the right call when change is genuinely expensive and requirements are fixed (regulated hardware, fixed-price contracts). The skill is matching the model to the change profile, not picking a favourite.

Key ideaYou are never choosing whether to have a life cycle — only whether to make it explicit. Picking a model is picking how you handle the cost of change.

TakeawayMemorise the six phases and the two model families (predictive vs adaptive) — this is reliable midterm material and the spine of the whole course.

Notes: 01 · Software Development Life Cycle · Read: Essentials of Software Engineering, ch. on process models — focus on the trade-off table comparing Waterfall, iterative, and Agile.

Module 2 · Session 3

Tooling — the developer's environment

Before writing serious code, set up the toolbox: an editor, a place to host and version code, and an AI pair-programmer. These are the daily instruments for everything that follows.

Learning outcomes

Configure a productive IDE and use GitHub as the hub for code and collaboration.
Use an AI coding assistant critically, in line with the course AI policy.

Session 3 · Live

Tools overview and setup

Objective: stand up the working environment every later lab depends on.

IDEs: VS Code — the editor, extensions, integrated terminal, and debugger as one workspace. The integrated debugger (breakpoints, watch, step-through) is worth learning early; it replaces print-statement debugging and saves hours on the assignments.
GitHub — remote hosting for repositories, pull requests, issues, and Actions; the backbone of the course's CI/CD. A pull request is not just code transport — it is the review and discussion surface where quality gates live.
GitHub Copilot — AI code completion, used as an assistant whose output you still validate. Per the course AI policy, suggestions are a starting point you must understand and be able to defend, not an answer to paste.

Core concept · Version control with GitA distributed system that records every change as a commit, lets parallel work happen on branches, and merges it back. GitHub adds the shared remote, pull requests, and automation. This is the substrate for everything that follows — CI/CD, IaC, and the group project all run through git history.

First push — the loop you will repeat all semester# stage, commit, and publish a change git add . git commit -m "feat: add health-check endpoint" git push origin main # or via a feature branch + pull request (preferred for the group project) git switch -c feat/health-check git push -u origin feat/health-check # then open a PR on GitHub

Common pitfallCommitting secrets (API keys, .env files) or build output. Add a .gitignore before your first commit — a secret pushed once is leaked forever, even if you delete it later (Session 28 returns to this).

Key ideaA fluent environment is leverage: time spent making the editor, version control, and assistant work together pays back on every assignment.

TakeawayGet the commit → push → PR loop into muscle memory now; the deployment, container, and IaC sessions all assume it.

Notes: 02 · Git Basics

Module 3 · Sessions 4–6

Design Patterns

Reusable solutions to recurring design problems, organised by the three Gang-of-Four families. Each session pairs a category with hands-on exercises so the patterns land as code, not vocabulary.

Learning outcomes

Recognise the creational, structural, and behavioural pattern families.
Apply each pattern where it genuinely reduces coupling — and recognise when it would only add noise.

Session 4 · Live

Creational design patterns

Objective: control how objects are created, decoupling construction from use.

Singleton — guarantees a single shared instance with a global access point (config, connection pools, loggers). It works by hiding the constructor and exposing one accessor that lazily creates and caches the instance.
Builder — assembles a complex object step by step, separating construction from representation. Ideal when an object has many optional parameters: a fluent chain reads far better than a constructor with ten arguments.
Factory Method — defers which concrete class to instantiate to a subclass, so callers depend on an interface and adding a new variant doesn't touch existing call sites (the Open/Closed principle in action).
Hands-on exercises — implement each pattern in code.

Core concept · Design patternA named, reusable solution to a problem that recurs in object-oriented design. It is a template for how classes and objects collaborate — not copy-paste code.

Builder — readable construction over a telescoping constructorServer server = new ServerBuilder() .host("0.0.0.0").port(8080) .tls(true).maxConnections(500) .build(); // vs new Server("0.0.0.0", 8080, true, 500, ...)

Common pitfallSingleton as a hiding place for global mutable state. It eases sharing but makes code hard to test (you can't swap it for a fake) and creates hidden coupling. Prefer dependency injection — pass the instance in — and reserve Singleton for genuinely stateless or truly-single resources.

Key ideaCreational patterns answer one question: who decides what gets built, and when? Push that decision behind an interface and the rest of the system stops caring.

TakeawayBe able to name the intent of each pattern in one sentence and recognise it in code — exam questions often show a snippet and ask which pattern it is.

Notes: 03 · Design Patterns · Read: the Gang-of-Four creational chapter — focus on intent and when not to use, not the UML.

Session 5 · Live

Structural design patterns

Objective: compose objects and classes into larger structures while keeping them flexible.

Adapter — wraps an incompatible interface so two classes that weren't designed together can collaborate; the classic use is fitting a third-party library to your own interface so you can swap it later.
Proxy — a stand-in that controls access to another object, implementing the same interface so callers can't tell the difference (lazy loading, caching, access control, remote calls).
Facade — a single simplified interface over a complex subsystem, reducing the surface area clients must learn and decoupling them from internal churn.
Hands-on exercises — wire the patterns into a small design.

Core concept · Composition over inheritanceStructural patterns mostly work by wrapping objects (composition) rather than extending classes (inheritance). Composition keeps coupling loose and behaviour swappable at runtime, where deep inheritance hierarchies become rigid and brittle.

Common pitfallConfusing Adapter, Proxy, and Decorator — all wrap an object. The tell is intent: Adapter changes the interface, Proxy guards the same interface, Decorator adds behaviour to the same interface.

Key ideaStructural patterns are about fit: they let you change how parts connect without rewriting the parts themselves.

TakeawayWhen integrating any external library, put an Adapter or Facade in front of it — your code then depends on your interface, and replacing the vendor is a one-class change.

Notes: 03 · Design Patterns

Session 6 · Live

Behavioural design patterns

Objective: manage how objects communicate and divide responsibility at runtime.

Observer — a subject notifies its dependents automatically when its state changes; the basis of event systems, UI bindings, and pub/sub. Subscribers register a callback and are decoupled from the publisher.
Strategy — encapsulates interchangeable algorithms behind a common interface, swappable at runtime; it replaces a sprawling if/else or switch over "modes" with a set of small, testable classes.
Command — turns a request into an object carrying its parameters, enabling queuing, logging, retry, and undo — the request becomes data you can store and replay.
Hands-on exercises — implement the interaction patterns.

Core concept · Behavioural patternsThey govern how objects communicate and divide responsibility at runtime. The common move is to extract the varying behaviour into its own object (a strategy, a command, an observer) so the rest of the system depends on a stable interface rather than a concrete algorithm.

Strategy — swap an algorithm without touching the caller# each strategy implements the same interface sorter = Sorter(strategy=QuickSort()) sorter.run(data) sorter.strategy = MergeSort() # behaviour changes, caller doesn't sorter.run(data)

Common pitfallReaching for Observer and ending up with untraceable "spooky action at a distance" — a state change fires a cascade of listeners you can't follow in a stack trace. Keep the event graph small and name your events clearly.

Key ideaBehavioural patterns trade compile-time wiring for runtime flexibility — favour composition and interfaces over hard-coded control flow.

TakeawayA big switch statement on a "type" field is almost always a Strategy or State pattern waiting to be extracted.

Notes: 03 · Design Patterns

Module 4 · Sessions 7–8

General principles & typical bad practices

The principles that keep code maintainable, and the smells that signal it isn't. Where patterns are the positive vocabulary, this module is the diagnostic one.

Learning outcomes

Apply SOLID and the informal principles (DRY, KISS) to real code.
Spot common code smells and reason about the refactoring they call for.

Session 7 · Live

Software development general principles & typical bad practices

Objective: build a shared vocabulary for what makes code good and what makes it rot.

SOLID principles — Single responsibility (one reason to change), Open/closed (extend without modifying), Liskov substitution (subtypes honour their base type's contract), Interface segregation (many small interfaces beat one fat one), Dependency inversion (depend on abstractions, not concretions). Together they keep OO systems easy to extend and hard to break.
DRY, KISS & other informal principles — Don't Repeat Yourself (one authoritative source for each piece of knowledge); Keep It Simple (the simplest thing that works); plus YAGNI (don't build what you don't yet need). Heuristics, not laws — DRY taken too far creates the wrong abstraction.
Code smells — surface symptoms that hint at deeper design problems: long methods, duplicated code, magic numbers, god objects, long parameter lists, feature envy. Each maps to a known refactoring.

Core concept · SOLIDFive design principles that, applied together, keep object-oriented systems easy to extend and hard to break: each class has one reason to change, is open to extension but closed to modification, and depends on abstractions rather than concretions.

Common pitfallOver-applying the principles — splitting every class into single-method fragments or hiding everything behind interfaces "for SOLID's sake". This is its own smell (needless complexity). Principles serve readability and change; if a "fix" makes the code harder to follow, it isn't one.

Key ideaA code smell isn't a bug — it's a warning. The fix is almost always a refactor that restores a violated principle, not a patch.

TakeawayBe able to name the SOLID letters and give a one-line smell + refactoring for each — this pairs directly with the patterns from Sessions 4–6.

Notes: 04 · Bad Practices & Code Smells · Read: Essentials of Software Engineering on design quality — focus on the link between a smell and the principle it violates.

Session 8 · Live

Consolidation: principles, patterns & bad practices

Objective: bring tools, the three pattern families, and the principles/bad-practices material together into one working picture.

Tools overview & setup recap — the environment from Module 2, now in service of pattern-driven code and the refactoring you'll do here.
Creational, structural & behavioural patterns — reviewed as one coherent catalogue, grouped by the question each family answers (who builds it / how it fits / how it talks).
General principles & bad practices — applying SOLID/DRY/KISS to clean up smelly code, choosing the pattern that restores the violated principle.

Connects toThis session is the bridge to the midterm: it ties the patterns (Sessions 4–6) to the principles (Session 7) and to the SDLC's design phase (Session 2). A good revision exercise is to take a smelly snippet, name the smell, name the violated principle, and name the pattern that fixes it.

Key ideaPatterns and principles aren't separate topics — patterns are how you express the principles in structure.

TakeawayUse this consolidation to build a one-page cheat sheet (pattern → intent, principle → smell → fix); it doubles as midterm revision.

Notes: 03 · Design Patterns · 04 · Code Smells

Module 5 · Sessions 9–10

Software backend — architecture & development

How the server side is shaped and built: the architectural choices that decide how a system scales, then the concrete libraries that turn that architecture into a running backend.

Learning outcomes

Compare backend architectures and explain where APIs and microservices fit.
Build a backend with an HTTP framework and an ORM.

Session 9 · Live

Software backend architectures

Objective: understand how backend systems are structured and exposed.

Architectures — monolith (one deployable, simplest to start), layered/N-tier (presentation → business → data, the default for most apps), and service-oriented / microservices (many deployables). The forces: team size, scaling needs, and how independently parts must change.
APIs — the contracts through which clients and services talk, typically REST over HTTP: resources addressed by URL, acted on with verbs (GET/POST/PUT/DELETE), exchanging JSON, with status codes signalling the outcome.
Microservices — decomposing a system into small, independently deployable services that each own their data and communicate over the network. Powerful but costly: you trade in-process method calls for network calls, distributed transactions, and far more moving parts to operate.

Core concept · MicroservicesAn architecture in which an application is a suite of small services, each running in its own process, communicating over lightweight APIs, and independently deployable. The trade is operational complexity for independent scaling and deployment.

A REST contract reads as resource + verb + statusGET /api/rooms → 200 list rooms POST /api/rooms → 201 create a room (body: JSON) GET /api/rooms/42 → 200 one room / 404 if absent DELETE /api/rooms/42 → 204 no content

Common pitfallSplitting into microservices too early ("distributed monolith"): services so chatty and co-dependent that you get all the network pain and none of the independence. Start as a well-layered monolith with clear module boundaries; extract a service only when one part genuinely needs to scale or deploy on its own.

Key ideaMicroservices are an organisational choice as much as a technical one — don't reach for them until a monolith's coupling is actually slowing you down.

TakeawayKnow the three architecture styles and one honest pro/con for each; "monolith-first" is the defensible default answer in an exam.

Notes: 05 · Software Architectures · 08 · Backend Components

Session 10 · Live

Software backend development

Objective: get hands-on with the libraries that implement a backend.

HTTP frameworks — routing requests to handler functions, middleware (auth, logging, CORS) that runs around them, and request/response handling. A framework like Flask, FastAPI, or Express turns "a function" into "an endpoint" with a decorator or route registration.
ORM libraries — Object-Relational Mapping: working with the database through objects (a Room class ↔ a rooms table) instead of raw SQL, with migrations to version the schema.
Other tools — supporting libraries for validation (rejecting bad input at the edge), configuration (env-driven settings), and serialization (object ↔ JSON).

Core concept · ORMA layer that maps database tables to objects in code, so persistence reads as method calls on domain objects rather than hand-written SQL — at the cost of some control over the generated queries.

A route + an ORM query (FastAPI-style)@app.get("/rooms/{id}") def get_room(id: int): return db.query(Room).filter(Room.id == id).first() # ORM builds: SELECT * FROM rooms WHERE id = ? LIMIT 1

Common pitfallThe N+1 query problem: looping over results and lazily loading a relation each iteration fires one query per row. Watch the SQL the ORM emits and use eager loading / joins — the convenience hides real database cost.

Key ideaFrameworks and ORMs trade some control for a great deal of speed; know what they generate so the abstraction never becomes a black box.

TakeawayThis is the session your Assignment 1 app leans on most — a few routes backed by an ORM model is the whole minimal backend.

Notes: 08 · Backend Components

Module 6 · Session 11

Software quality & testing

Quality is engineered in, not inspected on. This module covers the testing levels and the discipline — TDD — that makes tests drive design rather than trail behind it.

Learning outcomes

Distinguish unit, integration, regression, performance, and acceptance testing.
Practise Test-Driven Development to let tests shape the code.

Session 11 · Live

Software quality & testing

Objective: build a complete testing plan and practise writing tests first.

Unit testing — isolating the smallest pieces (functions, methods) and verifying them independently, mocking out collaborators. Fast and numerous; they pinpoint exactly what broke.
Integration testing — checking that components work together across their boundaries (code + real database, service + service). Slower but catches the wiring bugs units miss.
Regression testing — re-running the existing suite to confirm new changes haven't broken old behaviour; this is what makes a CI pipeline worth having.
Performance testing — measuring latency and throughput under load to find where the system degrades before users do.
Acceptance testing — confirming the software meets the agreed business criteria, ideally expressed as scenarios the stakeholder recognises.
Hands-on TDD — write a failing test, make it pass, refactor — repeat.

Core concept · Test-Driven DevelopmentA workflow where you write a failing test before the code that satisfies it, then refactor — the red/green/refactor loop. Tests become the executable specification and a safety net for change.

Red → green: write the failing test first# 1. RED — write the test, watch it fail def test_total_includes_tax(): assert price_with_tax(100, 0.21) == 121 # 2. GREEN — simplest code that passes def price_with_tax(net, rate): return net * (1 + rate) # 3. REFACTOR — clean up with the test as a safety net

Common pitfallChasing a coverage number. 100% coverage of trivial getters proves nothing, while a high figure can hide untested edge cases. Test behaviour and boundaries, not lines — and beware brittle tests coupled to implementation detail that break on every refactor.

Key ideaThe test pyramid: many fast unit tests at the base, fewer integration tests above, a thin layer of slow end-to-end tests on top. Coverage is a floor, not a ceiling.

TakeawayThe five test levels and the pyramid are exam staples; in practice, the unit tests you write here become the gate your CI pipeline (Session 13) enforces.

Notes: 06 · Testing

Module 7 · Session 12

Frontend development

The browser as a runtime: the two rendering architectures, the three core web languages, and the tools for inspecting what actually runs.

Learning outcomes

Contrast single-page and server-side-rendered architectures.
Work fluently with HTML, CSS, JavaScript, and browser dev tools.

Session 12 · Live

Frontend development

Objective: understand how the client side renders and how to build it.

SPA vs SSR architectures — Single-Page Apps load one shell then render in the browser via JavaScript (rich interactivity, slower first paint, harder SEO); Server-Side Rendering ships ready-made HTML per request (fast first paint, SEO-friendly, more server work). Modern frameworks (Next, Nuxt) blend both — render on the server, then "hydrate" in the browser.
HTML, JS & CSS basics — the three separated concerns of every page: HTML is structure (the DOM), CSS is presentation, JavaScript is behaviour. Keeping them separate is the frontend version of single responsibility.
Browser dev tools — Elements (inspect/edit the live DOM and CSS), Console (run JS, read errors), Network (see every request, timing, payload), and Performance (profile jank). The same tools you'd use to debug this very page.

Core concept · SPA vs SSRSPA loads a single HTML shell and builds pages with JavaScript client-side; SSR builds the HTML on the server per request. The choice trades initial load and SEO against client-side richness — modern frameworks often blend both.

Connects toThese notes themselves are static server-rendered HTML with a small scoped <style> — the simplest end of the spectrum, and a deliberate contrast to a JavaScript-heavy SPA. Open the Network tab on this page to see how little it ships.

Key ideaThe browser is a constrained runtime; the rendering choice (SPA vs SSR) is the single biggest lever on perceived performance.

TakeawayBe able to argue SPA vs SSR from the requirements (SEO? offline? how interactive?) rather than from fashion — that reasoning is the examinable skill.

Notes: 09 · Frontend Foundations

Module 8 · Sessions 13–14

Software deployment

Getting working code into production safely: automation with GitHub Actions, the deployment process and strategies that limit blast radius, and the first encounter with Infrastructure as Code.

Learning outcomes

Automate deployment with GitHub Actions.
Compare deployment strategies and explain how IaC makes infrastructure reproducible.

Session 13 · Live

Software deployment (I)

Objective: automate the path from commit to deployed app.

Deployment automation with GitHub Actions — YAML workflows in .github/workflows/ triggered by events (push, PR) that run jobs of steps on a runner: check out code, install, test, build, deploy. This is the CI pipeline from the testing session, made real.
Assignment app deployment overview — applying the pipeline to the course's own application: every push runs the tests and, if green, deploys — exactly the loop Assignment 2 is graded on.

Core concept · CI/CD pipelineContinuous Integration merges and automatically tests every change frequently; Continuous Delivery/Deployment keeps the result always shippable and pushes it through automated stages. The pipeline is the automated assembly line from commit to production.

A minimal GitHub Actions workflow# .github/workflows/ci.yml on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: pip install -r requirements.txt - run: pytest # red build blocks the merge

Common pitfallA pipeline that builds but never fails — tests that don't run, or a step that swallows errors. A green check must mean "safe to ship"; a pipeline you don't trust is worse than none, because it gives false confidence.

Key ideaIf deployment is a scripted pipeline rather than a manual ritual, releasing stops being an event and becomes routine.

TakeawayBeing able to write a basic ci.yml from memory is a likely practice-exam task and the core of Assignment 2.

Notes: 10 · Software Deployment · Read: The DevOps Handbook on continuous integration — focus on the "keep main always deployable" principle.

Session 14 · Live

Software deployment (II)

Objective: choose deployment strategies and treat infrastructure as code.

Software deployment process — building a versioned artifact once, then promoting that same artifact through environments (dev → staging → prod), with a defined rollback path if it misbehaves.
Deployment strategies — blue-green (two identical environments, switch traffic instantly, roll back by switching back), canary (release to a small % first, watch metrics, then widen), rolling (replace instances batch by batch). Each limits the blast radius of a bad change differently.
Infrastructure as Code — defining servers, networks, and services in version-controlled declarative files (e.g. Terraform), so an environment is created by running code, not by clicking in a console.

Core concept · Infrastructure as Code (IaC)Managing and provisioning infrastructure through machine-readable definition files rather than manual setup. The same code, applied twice, yields identical environments — reproducible, reviewable, and version-controlled.

Declarative IaC — describe the desired state, let the tool reconcile# Terraform: this *is* the server, in version control resource "aws_instance" "app" { ami = "ami-0abcd1234" instance_type = "t3.micro" tags = { Name = "sddo-app" } } # terraform plan → preview · terraform apply → make it real

Common pitfallConfiguration drift — someone fixes prod by hand, and now the running infra no longer matches the code. The whole value of IaC evaporates the first time the console is the source of truth instead of the repo. Change infrastructure only through the code.

Key ideaA blue-green or canary release limits blast radius: you expose a change to a slice of traffic (or a parallel environment) and can roll back instantly if it misbehaves.

TakeawayKnow all three strategies and one sentence on what each protects against; IaC's "reproducible by re-running code" is the line examiners look for.

Notes: 10 · Software Deployment

Module 9 · Session 15

DevOps frameworks overview

Steps back to define DevOps properly and survey the frameworks and lean thinking that give it structure — the conceptual centre of the second half of the course.

Learning outcomes

Define DevOps and place the common frameworks against it.
Relate Lean product management to the DevOps value stream.

Session 15 · Live

DevOps frameworks overview

Objective: consolidate what DevOps is and the frameworks that operationalise it.

What is DevOps? — the full definition now that you've seen the practices: culture, automation, measurement, and sharing (CAMS/CALMS) across Dev and Ops, aimed at fast, reliable, frequent delivery.
DevOps frameworks overview — the models used to structure adoption: CALMS (Culture, Automation, Lean, Measurement, Sharing) and the Three Ways (Flow, Feedback, Continual Learning). They are lenses for assessing maturity, not checklists of tools.
Lean product management — maximising value while minimising waste, pulling small batches of prioritised work into the delivery pipeline and validating them with real feedback.

Core concept · The Three WaysThe principles underpinning DevOps (from The DevOps Handbook): Flow (fast left-to-right delivery), Feedback (fast right-to-left signals), and Continual Learning & Experimentation (a culture that improves from both).

Connects toThis is the conceptual hinge of the course. Everything before it (CI/CD, testing, deployment strategies) is now reframed as Flow; monitoring and SRE (Sessions 20, 22) are Feedback; the retrospective (Session 33) is Continual Learning. The four Accelerate metrics — deployment frequency, lead time, MTTR, change-fail rate — are how you measure all three.

Key ideaDevOps frameworks don't prescribe tools — they prescribe principles. Flow, feedback, and learning survive any change of vendor.

TakeawayMemorise the Three Ways and the four Accelerate metrics — they are the most reusable framing on the final and the vocabulary the group project is judged against.

Notes: Accelerate · The DevOps Handbook · Read: Accelerate ch. 1–2 — focus on the four delivery metrics and why they predict organisational performance.

Module 10 · Sessions 16–18

Review, midterm & Assignment 2 kick-off

The midpoint checkpoint: reviewing Assignment 1, sitting the midterm, and launching the second half's group/individual work.

Learning outcomes

Consolidate the first half of the course under exam conditions.
Form groups and scope Individual Assignment 2.

Session 16 · Live

Review Assignment 1 & midterm Q&A

Objective: close out Assignment 1 and prepare for the midterm.

Review Individual Assignment 1 — feedback on the minimal app built in the first weeks.
Summarise & discuss midterm content — what's examinable and how it will be tested.

Key ideaThe review is itself a feedback loop — the same principle the course teaches, applied to your own learning.

Session 17 · Live

Midterm exam

Objective: assess the first half of the course (≈80 min, one session).

Midterm exam — worth 15% of the final grade; the date is tentative and confirmed two weeks ahead.

Notes: Quiz & midterm keys

Session 18 · Live

Midterm review & Assignment 2 distribution

Objective: review the midterm and launch the second-half project work.

Midterm exam review — going through the paper and common mistakes.
Group & Individual Assignment 2 — distribution of groups; Assignment 2 improves the app with DevOps practices.

Notes: Project briefs

Module 11 · Session 19

Scrum framework

The Agile framework that structures the group assignment: fixed iterations with explicit feedback loops, and the planning tools that support them.

Learning outcomes

Explain Scrum's roles, events, and artifacts.
Use planning tools to run sprints for the group project.

Session 19 · Live

Scrum framework

Objective: adopt Scrum as the operating rhythm for the team assignment.

Scrum framework — 3 roles (Product Owner owns the what and the backlog; Scrum Master owns the process; Developers own the how), 5 events (the Sprint container, plus Planning, Daily, Review, Retrospective), and 3 artifacts (Product Backlog, Sprint Backlog, Increment), each with a "definition of done".
Scrum planning tools — boards and backlogs (e.g. GitHub Projects, linked to the same repo and issues) for managing the sprint: columns for To-do → In-progress → Done, items estimated and pulled into the sprint.

Core concept · ScrumA lightweight Agile framework for delivering work in fixed-length sprints with feedback at the start, daily, and end of each. It defines roles, events, and artifacts — not engineering practices — and exposes problems rather than solving them.

Common pitfall"Cargo-cult Scrum" — running the ceremonies (especially a status-report Daily that's really for the manager) without the inspect-and-adapt intent. The Daily is for the Developers to re-plan their day, not to report upward; a Retro whose actions are never done is theatre.

Key ideaScrum is a framework, not a methodology: it tells you the events and roles, not how to engineer. Running the ceremonies without the principles is cargo-cult Agile.

TakeawayLearn 3 roles / 5 events / 3 artifacts cold — and actually run them on the group project, because Sessions 31–33 grade the Review and Retro you do here.

Notes: 07 · Scrum

Module 12 · Session 20

Software maintenance & operations

Software isn't done when it ships — it's observed and maintained. This module introduces monitoring and wiring an app to a monitoring service.

Learning outcomes

Configure diagnostic settings, logs, and performance monitoring.
Connect a running application to a monitoring service.

Session 20 · Live

Software maintenance and operations

Objective: make a running system observable.

Monitoring — the three pillars: logs (timestamped events), metrics (numeric time-series like latency and error rate), and traces (a request's path across services). Diagnostic settings and log analytics turn raw output into queryable signal.
Connecting an app to a monitoring service — instrumenting the application (a logging library, a metrics SDK, an agent) so signals flow to a dashboard and alerts fire on thresholds.

Core concept · ObservabilityThe ability to understand a system's internal state from its external outputs — logs, metrics, and traces. Monitoring tells you that something is wrong; observability helps you ask why.

Common pitfallAlert fatigue — wiring an alert to every metric until the on-call ignores them all. Alert on symptoms users feel (error rate, latency), not on every internal blip; this is exactly what the SLOs of Session 22 formalise.

Key ideaYou cannot operate what you cannot see. Instrumentation is part of building the feature, not an afterthought.

TakeawayLogs / metrics / traces — name the three pillars and what each answers; this feeds straight into SRE's SLIs next session.

Notes: 10 · Software Deployment

Module 13 · Session 21

Distributed architecture

How systems are structured when they grow beyond a single deployable unit — and the law that explains why their shape mirrors the teams that build them.

Learning outcomes

Explain loose coupling, microservices, and evolutionary architecture.
Apply Conway's Law to architectural and team decisions.

Session 21 · Live

Distributed architecture

Objective: design systems that scale and evolve across independent parts.

Loosely coupled architecture — components depend on one another as little as possible (via stable interfaces, async messaging), so each can change and deploy independently; the opposite is the tangle that makes a monolith hard to evolve.
Microservices — revisited as a distributed-systems concern: the network is unreliable, data consistency is now eventual not transactional, and partial failure must be designed for (timeouts, retries, circuit breakers).
Evolutionary architecture — designing for change so the system is guided through incremental, reversible decisions, with "fitness functions" (automated checks) guarding key properties as it grows.
Conway's Law — organisations design systems that mirror their own communication structure; ignoring it makes your architecture fight your org chart.

Core concept · Conway's Law"Any organisation that designs a system will produce a design whose structure copies the organisation's communication structure." In practice: your architecture will resemble your org chart — so shape the teams to get the architecture you want (the "inverse Conway manoeuvre").

Common pitfallAssuming "distributed" means "loosely coupled". A system can be spread across many services yet tightly coupled (every change touches several at once) — a distributed monolith with all the network cost and none of the independence. Coupling is about dependency, not deployment topology.

Key ideaArchitecture and org structure are two views of one thing. Loose coupling in the code requires loose coupling between the teams.

TakeawayConway's Law and the inverse manoeuvre connect this course to Team Topologies — a likely discussion/essay prompt on management trade-offs (objective 06).

Notes: 05 · Software Architectures · Team Topologies · Read: Team Topologies — focus on the four team types and three interaction modes.

Module 14 · Session 22

DevOps operations — SRE

The operational discipline of running reliable services at scale: Site Reliability Engineering, incident management, and the service-level vocabulary that defines "reliable".

Learning outcomes

Explain SRE and how it handles incidents.
Distinguish SLA, SLI, and SLO and use them to set reliability targets.

Session 22 · Live

DevOps operations

Objective: operate services reliably and respond to failure systematically.

Site Reliability Engineering (SRE) — Google's approach of applying software engineering to operations: automate toil away, treat reliability as a feature, and cap manual ops work so engineers keep improving the system instead of firefighting it.
Incident management — detecting, responding to, and learning from outages: clear roles (incident commander), a timeline, and a blameless post-mortem that fixes the system, not the person.
Continuous monitoring: SLA, SLI, SLO — built directly on the logs/metrics of Session 20: the measured indicator, the internal target, and the externally promised level.

Core concept · SLI / SLO / SLAAn SLI is a measured indicator (e.g. % of fast requests); an SLO is the internal target for that indicator; an SLA is the externally promised level with consequences if missed. The gap below an SLO is the error budget that licenses change.

From metric to budgetSLI: 99.3% of requests < 300ms this month (measured) SLO: 99.0% of requests < 300ms (target) SLA: 99.0% or service credits owed (promised to customer) → error budget = 1.0% may be "spent" on risky releases

Common pitfallSetting an SLO at 100% (or letting marketing promise it). Perfect reliability is unattainable and freezes all change; the error budget exists precisely so velocity and reliability are traded openly rather than fought over.

Key idea100% reliability is the wrong target — it's unattainable and stifles change. An error budget makes the trade-off between reliability and velocity explicit.

TakeawayBe crisp on SLI vs SLO vs SLA (measured / target / promised) and what an error budget licenses — a favourite exam discrimination.

Notes: 11 · DevOps Security · Accelerate

Module 15 · Sessions 23–26

DevOps continuous delivery

The engine room of DevOps over four sessions: delivery pipelines and strategies, containers, container infrastructure in the cloud, and modular Infrastructure as Code — directly feeding Assignment 2 and the group project.

Learning outcomes

Run continuous delivery with appropriate deployment strategies.
Containerise an app and deploy containers via GitHub workflows.
Modularise Infrastructure as Code for reuse across assignments.

Session 23 · Live

DevOps continuous delivery (I)

Objective: establish continuous delivery and its release strategies.

Continuous Delivery overview — keeping software in a deployable state at all times through automation, so a release is a decision rather than a project. The deeper version of the CI pipeline from Session 13.
Deployment strategies — blue-green, canary, rolling — revisited in the CD context, now as automated steps the pipeline orchestrates and can roll back.
DevOps quality — building quality gates into the pipeline (tests, linting, security scans, coverage thresholds) so only good builds progress; quality is enforced by the machine, not by hope.

Core concept · Continuous DeliveryEvery change that passes automated tests is automatically prepared for a release to production. Releasing becomes a business decision (a button press), not an engineering scramble. Continuous Deployment goes one step further and releases automatically.

Common pitfallConfusing Continuous Delivery (always ready to release, human presses the button) with Continuous Deployment (every green build auto-releases). The exam rewards the distinction; reaching for full Continuous Deployment without strong tests and monitoring ships bugs to users automatically.

Key ideaThe pipeline is where quality is enforced. A change that can't pass the gates never reaches users.

TakeawayDelivery = ready to ship on demand; Deployment = ships itself. Both demand the test and monitoring discipline from earlier sessions.

Notes: 10 · Software Deployment

Session 24 · Live

DevOps continuous delivery (II) — containers

Objective: package an application to run identically anywhere.

Docker containers introduction — packaging an app with its dependencies into a portable, isolated image defined by a Dockerfile; a running instance of that image is a container. Image vs container is the layers-vs-running-process distinction.
Hands-on: running an app in a local container — docker build to create the image, docker run to start it, mapping a port so the host can reach the app.

Core concept · ContainersA container bundles an application with everything it needs to run into a single isolated unit that shares the host OS kernel. Unlike a VM, it's lightweight and starts in seconds — and "it works on my machine" stops being an excuse because the machine ships with the code.

A minimal DockerfileFROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"] # docker build -t sddo-app . && docker run -p 8080:8080 sddo-app

Common pitfallBloated, insecure images: copying everything (including .git and secrets) and starting FROM a full OS. Use a slim/minimal base, a .dockerignore, and order layers so dependencies cache separately from source — small images build and deploy faster and expose less attack surface.

Key ideaContainers make the deployment artifact and the development environment the same thing — the image you test is the image you ship.

TakeawayBeing able to write a basic Dockerfile is a near-certain practice-exam task and the heart of Assignment 2's containerisation.

Notes: 10 · Software Deployment

Session 25 · Live

DevOps continuous delivery (III) — containers in the cloud

Objective: run containers in cloud infrastructure through automated workflows.

Container infrastructure in the cloud — a registry stores built images; orchestration (Kubernetes, or a managed service like ECS/Cloud Run) schedules, scales, and heals running containers; managed services trade control for less ops burden.
Deploying containers with GitHub workflows — the pipeline builds the image, pushes it to the registry, and tells the platform to roll out the new tag — the Session 13 workflow, now shipping a container instead of raw code.

Core concept · Orchestration & registryA registry is the versioned store of images (the artifact); an orchestrator runs them — placing containers on hosts, restarting failed ones, scaling replicas to match load, and replacing old versions on deploy. Together they turn "a container on my laptop" into "a fleet that stays up".

Common pitfallPushing only the latest tag. Without immutable version tags (e.g. the git SHA) you can't tell what's running or roll back precisely — and two deploys can silently mean different code. Tag every image with its commit.

Key ideaOnce a container deploys from a workflow, scaling and rollback become configuration, not manual operations.

Takeawaybuild → push to registry → orchestrator rolls out: know this three-step flow; it's the production version of the local docker run from last session.

Notes: 10 · Software Deployment

Session 26 · Live

DevOps continuous delivery (IV) — IaC modularization

Objective: structure Infrastructure as Code so it can be reused and composed.

Infrastructure as Code modularization — breaking IaC into small, parameterised, reusable modules (a "network" module, a "service" module) instead of one giant file, then composing them — and using the same module to stamp out identical dev / staging / prod with different inputs.
Modularization strategy for Assignment II & the Group Assignment — applying modular IaC to the course projects so the team's environments are reproducible and reviewable, not hand-built.

Core concept · IaC modularizationComposing infrastructure from small, parameterised, reusable modules (like functions for infrastructure) — DRY applied to provisioning, so an environment is assembled from tested building blocks.

Connects toThis is Session 7's principles (DRY, single responsibility) applied to Session 14's IaC. The same trap also returns: over-modularising into so many tiny abstractions that the infrastructure becomes harder to read than the duplication it replaced.

Key ideaThe same design principles that keep code maintainable (DRY, single responsibility) apply to infrastructure once it becomes code.

Takeaway"Infrastructure is just code" is the through-line — patterns, principles, and review all transfer to provisioning.

Notes: 10 · Software Deployment

Module 16 · Sessions 27–28

DevOps security — DevSecOps

Shifting security left into the delivery pipeline: secure delivery and infrastructure, security culture and frameworks, and the practical handling of secrets and authentication.

Learning outcomes

Explain DevSecOps and how to secure delivery and infrastructure.
Manage secrets safely and implement authentication and 2FA.

Session 27 · Live

DevOps security (I)

Objective: make security a continuous, cultural part of delivery.

DevSecOps — integrating security into every stage of the lifecycle rather than bolting it on at the end, with automated checks as pipeline gates so insecure builds simply don't progress.
Secure software delivery — dependency scanning (SCA) for known-vulnerable libraries, container image scanning, static analysis (SAST), and signing artifacts so you can prove what you shipped wasn't tampered with.
Secure infrastructure — hardening the platform: least-privilege IAM, closed-by-default networking, patched base images, encryption in transit and at rest.
Security culture — making security everyone's responsibility from the first commit, not a separate team's final gate; threat-modelling a feature as you design it.
Security frameworks — structured standards for assessing and improving posture, notably the OWASP Top 10 (the most common web vulnerabilities — injection, broken auth, XSS) as a baseline checklist.

Core concept · DevSecOpsEmbedding security practices throughout the DevOps pipeline — "shifting left" so vulnerabilities are caught early, automatically, and continuously, instead of in a final audit. Security becomes a shared responsibility across Dev, Sec, and Ops.

Common pitfall"Shifting left" so hard the pipeline drowns in scanner noise that everyone overrides. Tune scanners, fail the build only on genuinely actionable findings, and pair automation with the culture so the gates are respected rather than bypassed.

Key ideaSecurity found late is expensive; security automated into the pipeline is cheap. Shift it left.

TakeawayKnow what "shift left" means and name a few automated controls (SCA, SAST, image scanning, signing) plus OWASP as the framework reference.

Notes: 11 · DevOps Security · Read: The DevOps Handbook security chapter — focus on integrating security into the daily pipeline.

Session 28 · Live

DevOps security (II)

Objective: handle secrets and identity correctly in practice.

Secure secrets management — keeping credentials, keys, and tokens out of code and in a managed store (a vault, or GitHub Actions secrets), so they can be rotated and audited centrally.
Authentication & 2FA — verifying identity (something you know) strengthened by a second factor (something you have/are); the difference between authentication (who you are) and authorization (what you may do).
Hands-on: cloud secret management — using a cloud vault to inject secrets at runtime (as env vars or mounted files) so the artifact stays secret-free.

Core concept · Secrets managementStoring and accessing sensitive values (passwords, API keys, certificates) through a dedicated, access-controlled service rather than hard-coding them — so secrets can be rotated, audited, and never committed to version control.

Inject at runtime — never bake into the image or commit# .env and real keys are git-ignored; code reads from the environment db_url = os.environ["DATABASE_URL"] # injected by the vault / CI # in GitHub Actions: env: DATABASE_URL: ${{ secrets.DATABASE_URL }}

Common pitfallA secret committed once is leaked forever — rotating it is the only real fix, because git history (and every clone and fork) still holds the old value. This is why Session 3 insisted on .gitignore before the first commit.

Key ideaA secret in the repository is a secret already leaked. Inject secrets at runtime from a vault, never bake them into the artifact.

TakeawaySecrets at runtime, never in the repo or image; auth ≠ authz; 2FA adds a factor. These are easy, certain marks if stated precisely.

Notes: 11 · DevOps Security

Module 17 · Sessions 29–30

SysAdmin basics

The systems-administration foundations under everything DevOps: secure network access, UNIX permissions, and a hands-on workshop tying them together.

Learning outcomes

Use VPNs, SSH tunnelling, and port forwarding for secure remote access.
Reason about UNIX user roles and permissions.

Session 29 · Live

SysAdmin basics (I)

Objective: access and secure remote systems the way operators do.

VPN, SSH tunnelling, port forwarding — encrypted channels for reaching private services securely: a VPN puts you "inside" the network; SSH local port forwarding tunnels a remote service to your localhost without exposing it publicly.
UNIX user roles — users, groups, and the read/write/execute permission bits (owner / group / other) that govern who can do what; root is all-powerful, so day-to-day work uses unprivileged users and sudo.

Core concept · SSH & least privilegeSSH provides an encrypted channel to a remote host; tunnelling and port forwarding extend it to reach otherwise-private services. UNIX permissions enforce least privilege — each user and process gets only the access it needs.

SSH key auth + a tunnel to a private databasessh -i ~/.ssh/id_ed25519 deploy@server # key-based login, no password ssh -L 5432:db.internal:5432 deploy@server # reach a private DB at localhost:5432 chmod 600 ~/.ssh/id_ed25519 # rw for owner only — sshd refuses loose keys

Common pitfallchmod 777 "to make it work". It grants everyone full access and is a classic security hole; private keys must be 600 or SSH rejects them. Default to the least permission that works, not the most.

Key ideaMost production access flows over SSH; understanding permissions and tunnelling is the difference between operating a server and locking yourself out of it.

TakeawayRead a permission string like rwxr-x--- and explain a port-forward command — concrete, examinable sysadmin skills under every managed cloud service.

Session 30 · Live

SysAdmin basics (II)

Objective: practise sysadmin skills hands-on.

SysAdmin workshop — applying remote-access and permission concepts on a live system.

Key ideaThe cloud abstracts servers but never removes them — sysadmin fundamentals stay relevant beneath every managed service.

Module 18 · Sessions 31–35

Sprint review, retrospective & final exam

The course closes by exercising the Scrum loop on the group project — a sprint review and a retrospective — before the final exam consolidates everything.

Learning outcomes

Demonstrate a delivered increment and gather feedback (review).
Reflect on the team's process and commit to improvements (retrospective).
Demonstrate mastery of the whole course under exam conditions.

Sessions 31–32 · Live

Sprint review exhibition

Objective: demonstrate the group's delivered increment to stakeholders.

Sprint review exhibition — presenting the working software built across the group assignment and collecting feedback.

Core concept · Sprint ReviewThe Scrum event at a sprint's end where the team demonstrates the increment to stakeholders and adapts the backlog from their feedback — inspection of what was built.

Key ideaA review demos working software, not slides. The feedback gathered reshapes the backlog.

Notes: 07 · Scrum · Group assignment

Session 33 · Live

Retrospective exhibition

Objective: inspect how the team worked and commit to improvements.

Retrospective exhibition — reflecting on the process (not the product) and identifying actionable improvements.

Core concept · Sprint RetrospectiveThe Scrum event where the team inspects how it worked and plans one or two concrete improvements — the engine of continuous improvement.

Key ideaThe retrospective targets how you worked, not what you built. A retro whose actions are ignored is theatre.

Notes: 07 · Scrum

Sessions 34–35 · Live

Final exam

Objective: assess the whole course (double session, ≈160 min).

Final exam — worth 30%, with separate theory and practice parts. A minimum of 3.5/10 is required in each part to pass, regardless of weighted average.

Key ideaThe final is gated per part: strength in one half cannot rescue a weak other half. Revise theory and practice together.

Notes: Quiz & midterm keys · Assessment rules

How Software Development & DevOps is built.

Overview

Learning objectives

Teaching methodology

Assessment

Final Exam

Individual Assignments

Exercises

Midterm Exam

Group Assignment

Pass, attendance & re-sit rules

Program, module by module

Foundations & the Software Development Life Cycle

Introduction & overview of Software Development and DevOps

Software Development Life Cycle (SDLC)

Tooling — the developer's environment

Tools overview and setup

Design Patterns

Creational design patterns

Structural design patterns

Behavioural design patterns

General principles & typical bad practices

Software development general principles & typical bad practices

Consolidation: principles, patterns & bad practices

Software backend — architecture & development

Software backend architectures

Software backend development

Software quality & testing

Software quality & testing

Frontend development

Frontend development

Software deployment

Software deployment (I)

Software deployment (II)

DevOps frameworks overview

DevOps frameworks overview

Review, midterm & Assignment 2 kick-off

Review Assignment 1 & midterm Q&A

Midterm exam

Midterm review & Assignment 2 distribution

Scrum framework

Scrum framework

Software maintenance & operations

Software maintenance and operations

Distributed architecture

Distributed architecture

DevOps operations — SRE

DevOps operations

DevOps continuous delivery

DevOps continuous delivery (I)

DevOps continuous delivery (II) — containers

DevOps continuous delivery (III) — containers in the cloud

DevOps continuous delivery (IV) — IaC modularization

DevOps security — DevSecOps

DevOps security (I)

DevOps security (II)

SysAdmin basics

SysAdmin basics (I)

SysAdmin basics (II)

Sprint review, retrospective & final exam

Sprint review exhibition

Retrospective exhibition

Final exam

Key concepts

Bibliography

Accelerate

The DevOps Handbook

Essentials of Software Engineering

Team Topologies