Project Maintenance and Deployment

This section explains how practicum projects are maintained, deployed, and managed after development.
It focuses on operational responsibilities, long-term continuity, and secure access control across rotating student cohorts.

Unlike CI/CD automation, this section covers the human processes and infrastructure decisions required to launch and maintain production systems.

---

Purpose

Because our projects are maintained by multiple student teams over time, our deployment and maintenance processes must be:

• Consistent and repeatable
• Documented clearly in the repository
• Secure and limited to approved roles
• Designed to outlive a single quarter or team

This section establishes expectations and policies to ensure project longevity, security, and maintainability.

---

Topics in This Section

🔧 Deployment Flow

How to responsibly deploy a practicum project to a hosting provider.
Includes build requirements, access permissions, approval steps, and rollback expectations.

Covers how to deploy, not CD theory.

🗃 Database Management

Standards and procedures for databases used in practicum projects.
Includes backups, migrations, student access policies, and data privacy requirements.

Applies to both SQL and NoSQL services.

🔐 Environment Secrets & Permissions

Policies for managing environment variables, GitHub secrets, cloud credentials, and access levels for student roles.

Prevents credential leaks and ensures secure turnover between cohorts.

---

Ownership & Responsibility

Role	Responsibilities
Professor	Final approval of deployment & access policies
TPM	Maintains credentials, access control, and deployment standards
Lead Engineer	Temporary deployment access; implements policies
PM	Supports documentation; may assist with secrets if approved
Students / Contributors	No deployment access; follow documentation standards

---

Expectations for All Projects

All practicum repositories must:

• Provide a README deployment section, even if not deployed yet
• Include a .env.example file
• Document database usage (if applicable)
• Avoid storing sensitive data in source control
• Retain deployment history and access records when projects change hands

Even if a project is never deployed, it must be deploy-ready.

---