Project Proposal: Group scheduling app with IaC multi-deployment - #2996
Open
gruendlich wants to merge 1 commit into
Open
Project Proposal: Group scheduling app with IaC multi-deployment#2996gruendlich wants to merge 1 commit into
gruendlich wants to merge 1 commit into
Conversation
gruendlich
marked this pull request as ready for review
September 7, 2026 17:19
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Assignment Proposal
Title
Project: group scheduling app with IaC multi-deployment
Names and KTH ID
(agrund@kth.se)
(alerun@kth.se)
Deadline
11 October 2026
Category
Project
Description
We are building Schedular, a crab.fit-style group scheduling app, from scratch: a React
and TypeScript frontend, a Python backend (likely FastAPI), a database (TBD), KTH schedule
import, group creation, availability voting, calendar export and email reminders. The
codebase itself is largely AI-generated from an architecture plan we write up-front
(including API contracts).
CI on GitHub Actions runs the test suite, linting and static checks, and at least one
dependency/vulnerability scanner on every push. Infrastructure is defined as code: a
docker-compose setup for a dev deployment to our KTH VM, and Kubernetes manifests for a
production deployment on Google Cloud or comparable, both provisioned and updated via GitHub Actions
pipelines. CD automatically pushes to the KTH VM on relevant branches and to the GCP
cluster on merges to main. GitHub is used as the development platform throughout (repo,
issues, Actions). Time permitting, we might extend this with a monitoring dashboard with
heartbeat/circuit-breaker checks between containers, and look into an MLOps component,
scoped after the relevant lectures.
Relevance: The project integrates the core DevOps practices required by the course in
one coherent system: automated CI (tests, lint, dependency/vulnerability scanning),
automated CD to both a dev and a production environment, infrastructure as code for both
deployment targets.