Homework 3

Build and Operate a CD Pipeline

Design, build, and operate a continuous delivery pipeline that can carry an accepted source change into production and recover when a release does not behave as expected.

Continuous delivery Deployment Operations Supply chain Design

Release Date Sep 21, 2026

Due Date Oct 11, 2026

Weight 200 pts (+ 20 bonus pts)

Overview¶

In HW1 and HW2, you added automated checks to Tartan Tickets and secured its credentials. In this assignment, you will build a continuous delivery (CD) pipeline to deploy it to your CMU VM and keep it working.

Your pipeline must automate deployment of an approved source change. You choose the deployment tools and whether a person approves each release.

Your pipeline should let a (hypothetical) teammate answer four questions:

What is running, and where did it come from?
Why was this change allowed into production?
Did the release succeed?
How will we recover if it did not?

🎯 Learning Goals¶

After completing this assignment, you should be able to:

Design and justify a repeatable pipeline from approved source to production
Enforce release checks and trace deployed artifacts to their source and evidence
Verify application health and restore service through the release system
Review an AI-generated change, then release and roll it back with traceable evidence

🚩 Checkpoints¶

Checkpoint	Points	Due	Last accepted
Checkpoint A: Design Baseline	40 pts	Sep 27, 2026	Oct 1, 2026
Checkpoint B: Production Activation	100 pts	Oct 4, 2026	Oct 8, 2026
Checkpoint C: Final Submission	60 pts	Oct 11, 2026	Oct 15, 2026

Due and last-accepted times are 11:59 p.m. Eastern Time.

Late Days Carry Across Checkpoints

HW3A, HW3B, and HW3C use the same course-wide late-day balance. Each late day charged for HW3A or HW3B moves every remaining due time one day later; staff will record the adjusted due times in Canvas. Begin the Checkpoint C exercise once your Checkpoint B deployment works. The listed last-accepted times do not move.

Project Context¶

Your pipeline must deploy the complete Tartan Tickets application, including the services you build and the externally supplied payment service. Later assignments will build on this deployment.

Production VM and Deployment Tools

Each student receives a CMU VM. Deploy Tartan Tickets at https://<assigned-hostname>/ on port 443. Course staff already know your assigned hostname and will use this address for grading.

The course deployment guide on Canvas provides VM access instructions and HTTPS setup guidance.

Requirements¶

Keep the first version small

Reuse the checks and secret-handling approach you developed in HW1 and HW2. You can meet the requirements with one VM, a pipeline that rebuilds all application components, and a person approving releases. All 200 base points are achievable with manual release approval and manually initiated recovery. Once the required work is complete, you may attempt the two optional bonuses below.

Checkpoint A: Plan the Pipeline¶

At Checkpoint A, use the template below to commit hw3/DESIGN.md describing your proposed pipeline. Aim for 250–400 words, plus a diagram or numbered release sequence. Short bullets and sentence fragments are fine.

Template: hw3/DESIGN.md

# HW3 Design

## Release path
- How will a source change reach production? Show a diagram or numbered steps.
- Which checks and human decisions will allow or block a release?

## Design choice
- What is one important design choice, and what alternative did you consider for meeting the same requirement?
- Why does your choice fit this application and VM? What do you give up?

## Operation and evidence
- How will you find what is running, its source commit, and its pipeline run?
- How will you check that the application works?
- How will you restore a working version through your release system?
- Where will you find pipeline, release, and recovery records?
- What is one limitation of your approach?

## Implementation plan
- What already works, and what do you still need to build?
- What do you need to figure out before you can deploy?

Feedback on your plan

Staff will return brief feedback on on-time Checkpoint A submissions by Wednesday, September 30. Use it to address the most important gap before the deployment deadline on Sunday, October 4. You may continue building while waiting for feedback.

Checkpoint B: Deploy the Application¶

Build a pipeline that meets the five requirements below. You choose its trigger, tools, and whether a person approves releases; the pipeline must automate deployment. If you use GitHub Actions, every job must target the course-provided self-hosted runners with the labels published by course staff.

🏗️ Build¶

Produce container images for each application component you control, with a way to identify their exact contents. Report whether the build succeeded.

📐 Check¶

Run the required checks and obtain any required approval before release. Keep records showing their results and that they can block deployment.

Automatically block any application artifact containing a known critical vulnerability in a runtime component for which a fix is available before approval or deployment. You choose how and where to check. Exceptions to this rule are not allowed; document any exceptions to stricter rules you add.

For grading, staff use the cohort vulnerability database captured on October 8, 2026 (UTC). Later vulnerability disclosures do not affect your grade. Your pipeline may use newer vulnerability data and enforce stricter checks.

You may publish a candidate for inspection, but must not represent or deploy it as approved before the required checks pass.

📦 Deploy¶

Deploy an approved release to the course VM through repeatable automation, and report whether deployment succeeded. Deploy the same artifacts you checked: do not rebuild them during deployment or rely only on tags that can later point to different contents. A content digest identifies an artifact by its contents; another method is acceptable if it verifies exactly what was checked and deployed.

Keep records identifying the running release, its source commit, the pipeline run that produced or selected it, and the action that deployed it.

✅ Verify¶

Verify the core user journeys on the deployed application after deployment and recovery. Supply evidence of what you checked and the results, such as screenshots, a short recording, or output from your own checks. Leave the service healthy at Checkpoints B and C; interruptions during deployment and the recovery exercise are acceptable. A successful deployment command alone does not establish application health.

🩹 Recover¶

Use your release system to restore a working version and record the action. You may check the application and start recovery yourself; automatic rollback is optional. Document the steps so a teammate can release, inspect, and recover the application.

Getting started

Confirm VM access, produce an identifiable artifact, connect the release checks, and automate deployment. Verify the user journeys before rehearsing recovery.

Choose an approach you can build and operate:

Push from a workflow: Run deployment commands against the VM after checks pass. Decide how the workflow authenticates and records the result.
Pull from the VM: Have a VM process apply an approved release record. Decide how to record approval and report deployment status.
Use a deployment tool: Let a tool such as Komodo manage deployments and their history. Decide which checks and actions belong in the workflow or tool.

These approaches can overlap.

Update Your Design¶

Update hw3/DESIGN.md to describe the working pipeline:

Revise the release path, design choice, and limitation to match what you built. Mark completed work and remaining uncertainties.
Add brief steps a teammate can follow to release, identify what is running, check health, and recover.
Link the evidence, identifying the deployed source commit and exact artifacts directly or through a release record.

Operating steps and links may extend beyond Checkpoint A's word target. Preserve the original plan in Git history.

Checkpoint C: Release a Feature and Roll Back¶

Use your working Checkpoint B pipeline to release one small AI-generated feature, then roll back to the exact prior artifacts. The sequence is A → B → A: your working release, the feature release, and the original release restored. Rollback is the central outcome; the feature makes the difference between releases visible.

Record release A. Note its source commit and image digests, and preserve the images and release configuration needed to redeploy it.
Generate a feature PR with AI. Pick one feature from the menu below and have an AI tool generate the PR, such as a coding agent that opens it for you.
Review and test the PR as you would a teammate's. Fix it if needed, then merge it.
Deploy release B through your existing pipeline, with its required checks and any approval step.
Roll back to release A through your release system, and leave production running A.

Redeploy A's original artifacts; do not rebuild them. Reverting the source and rebuilding is not a rollback to A and earns at most half of the rollback points. You may start the rollback manually; no broken release is needed. Do not make unrecorded changes directly on the VM.

Feature Menu

Matching event count: The events page shows "Showing N events", and N updates as the sidebar filters change.
Sort events: A dropdown on the events page sorts events by date (soonest first) or by lowest starting price.
Copy confirmation number: A button on the order confirmation page copies the confirmation number to the clipboard and briefly shows "Copied".
Dark mode toggle: A header toggle switches between light and dark themes and remembers the choice across reloads.

Keep the PR to the frontend. You should not need to make any dependency updates, database or schema changes, or infrastructure changes.

Write the Final Report¶

Commit hw3/REPORT.md using the template below. Short bullets and links are enough. For each stage, identify the source commit and image digests, and link the pipeline run or deployment action. One screenshot per stage showing the feature's presence or absence and a working core user journey is enough to show the application works. Link your HW3 entry in DISCLOSURE.md for AI use rather than repeating it here.

Template: hw3/REPORT.md

# HW3 Report

- Feature: PR link and chosen feature. AI use: disclosure link.
- Review: What I checked and tested, the results, and any corrections (2–3 sentences).
- Rollback: How I restored A's original artifacts without rebuilding (one sentence).

| Stage | Release record (commit + digests) | Evidence links |
| --- | --- | --- |
| A: before | | |
| B: feature deployed | | |
| A: restored | | |

Optional Bonuses — Up to 20 Points¶

Attempt either or both bonuses using your existing pipeline and VM. Neither is required for the A → B → A exercise.

Automatic recovery — up to 10 points

When an application health check fails after deployment, automatically restore a known working release. For full credit, automatically verify that recovery restored application health and demonstrate that a healthy release stays deployed. Use a separate controlled failure demonstration for this bonus, and finish by restoring healthy release A.

Prevent overlapping deployments — up to 10 points

Request a second release while the first deployment is still running. Automatically queue or reject the second request so deployment steps cannot interfere. For full credit, account for both requests in the release records and verify that the final running release is identifiable and healthy.

For each claimed bonus, add a short entry to hw3/REPORT.md describing the demonstration and linking to its configuration, runs, release records, and health results. No separate submission or longer report is required.

Record Your AI-Use Disclosure¶

Before HW3A, add an ## HW3 heading to DISCLOSURE.md and briefly describe any AI tools you used and how you used them. If you did not use AI through Checkpoint A or B, say so. Checkpoint C requires an AI-generated PR. Before HW3B and HW3C, update the same entry so it covers your work through that checkpoint.

How Checkpoint Submission Works¶

Complete the checkpoint documents and disclosure, and commit them on main.
For HW3B, identify the deployed source commit and exact artifacts in hw3/DESIGN.md. For HW3C, identify both A and B and the restored A artifacts in hw3/REPORT.md. A linked release record may identify the artifacts.
Once the checkpoint's required work is ready, submit only the exact GitHub submission commit URL in the corresponding Canvas assignment.

Documentation-only commits

For B, submit the deployed source commit or a later commit on main containing only documentation changes since that source commit. For C, keep the feature commit on main and submit B's source commit or a later commit containing only documentation changes since B. Production must run restored release A; do not rebuild A or revert the feature on main just to make the submission match production. Documentation-only changes do not require redeployment. Other changes to application code, build configuration, or release automation must be deployed and reflected in the evidence before submission.

Keep evidence available

Link or precisely identify the evidence for each claim in your checkpoint documents. Use permanent links to runs and release records. If a record may expire or change, save a short export or screenshot in hw3/ and link it from the checkpoint document. Keep all required records available through the final checkpoint's last-accepted time.

Submission and Deliverables¶

Complete each checklist and use the corresponding Canvas submission.

HW3A: Design Baseline¶

Due Sunday, September 27 at 11:59 pm ET.

Last accepted Thursday, October 1 at 11:59 pm ET.

Commit hw3/DESIGN.md with your proposed pipeline, one design trade-off, and an implementation plan.
Add an HW3 entry to DISCLOSURE.md.
In HW3A on Canvas, submit the exact URL of that commit.

Open HW3A in Canvas

HW3B: Production Activation¶

Due Sunday, October 4 at 11:59 pm ET.

Last accepted Thursday, October 8 at 11:59 pm ET.

Use the pipeline to deploy the initial release to your assigned CMU VM on HTTPS port 443 and supply evidence that the core user journeys work.
Update hw3/DESIGN.md to describe the working pipeline, identify the deployed source commit and exact artifacts, and include evidence links and operating instructions.
Update the HW3 entry in DISCLOSURE.md.
In HW3B on Canvas, submit the exact URL of the commit containing your completed checkpoint documents.

Open HW3B in Canvas

HW3C: Feature Release and Rollback¶

Due Sunday, October 11 at 11:59 pm ET.

Last accepted Thursday, October 15 at 11:59 pm ET.

Use AI to generate one PR implementing a feature from the menu, then review and test it.
Deploy release B through your existing pipeline, roll back to the preserved release A artifacts, and leave production healthy on A.
Commit hw3/REPORT.md with the PR link, brief review and rollback notes, and an A → B → A evidence table. Link your AI-use disclosure and any bonus evidence.
Update the HW3 entry in DISCLOSURE.md to cover the complete assignment.
In HW3C on Canvas, submit the exact URL of the commit containing your completed checkpoint documents.

Open HW3C in Canvas

Grading¶

HW3 is worth 200 base points, with up to 20 bonus points awarded at Checkpoint C.

The assignment is worth 200 points (+ 20 bonus pts).

HW3A — Design Baseline40 pts

The design explains how a source change reaches production, including checks and human decisions.15 pts
The design defends one important choice against a reasonable alternative for this application and VM.10 pts
The design describes release identification, health checks, recovery, evidence locations, and one limitation.10 pts
The implementation plan distinguishes completed work from remaining steps and uncertainties.5 pts

HW3B — Production Activation100 pts

The pipeline produces identifiable container images for every application component the student controls and reports the build result.20 pts
Required checks and any required approval gate the release, with inspectable results.15 pts
The pipeline automatically blocks artifacts that fail the required vulnerability check before approval or deployment.10 pts
Repeatable automation deploys the complete application to the assigned CMU VM on HTTPS port 443 and reports the result.20 pts
Records verify that the deployed artifacts are the ones checked and identify their source commit, pipeline run, and deployment action.15 pts
Student-supplied evidence shows working core user journeys in the deployed application, and the documentation explains how to check application health.10 pts
A teammate can use the documented steps to release, identify the running version, and restore a working version through the release system with a record of the action.10 pts

HW3C — Feature Release and Rollback60 pts (+ 20 bonus pts)

The report explains how the student reviewed and tested the AI-generated PR, why it meets the feature's stated behavior, and any corrections made. A correction is not required if the implementation was already sound.0–10 pts
One AI-generated PR implements a feature from the menu within the stated scope, and screenshots show its behavior in the deployed application.10 pts
Release B reaches production through the existing pipeline with its required checks intact. Records identify its source commit, immutable artifact digests, pipeline run, and deployment action; student-supplied evidence confirms the application works.15 pts
The release system restores the exact preserved release A artifacts without rebuilding them. Records show matching artifact digests before and after rollback, screenshots show the feature is absent, and student-supplied evidence confirms the application still works. A recorded restore that rebuilds A's source instead earns at most half credit.0–20 pts
All three submissions identify the required commits and link to the required evidence. They preserve design and deployment history, include an up-to-date HW3 entry in DISCLOSURE.md, and keep secrets and large generated files out of the repository.5 pts

Bonus: Evidence shows automatic recovery from a failed release and acceptance of a healthy release.10 pts

Scoring levels

Points	Level	Description
10	Recovery verified	Meets the five-point tier, automatically verifies that recovery restored application health, and shows that a healthy release stays deployed.
5	Recovery triggered	A failed application health check automatically triggers restoration of a known working release, with records identifying the failed and restored releases.
0	Not demonstrated	The evidence does not demonstrate the five-point tier.

Bonus: Two release requests cannot interfere with each other's deployment steps.10 pts

Scoring levels

Points	Level	Description
10	Safe outcome verified	Meets the five-point tier, accounts for both requests in the release records, and verifies that the final running release is identifiable and healthy.
5	Overlap prevented	With one deployment still running, a second release request is automatically queued or rejected. Evidence shows that their deployment steps do not overlap.
0	Not demonstrated	The evidence does not demonstrate the five-point tier.