Waterfall SDLC Documentation for a University Course Registration & Scheduling Web Portal

9. Deployment Phase: Release, Migration, Verification, and Rollback

Deployment Objective

Release the approved application version to production before registration opens while preserving the ability to return safely to the previous stable state if release verification fails.

Pre-Deployment Checklist

• Approved release candidate identified by version.
• Production infrastructure and configuration validated.
• Database backup completed and recovery procedure verified.
• Database migrations reviewed and tested in the acceptance environment.
• Production secrets and identity integration configured.
• Monitoring, logs, health checks, and alerts enabled.
• Support and registrar teams informed of the deployment window.
• Rollback artifacts and responsible personnel available.
• Change ticket and production approval completed.

Deployment Procedure

1. Announce the approved maintenance or release window.
2. Confirm latest backups and monitoring health.
3. Deploy production database migrations.
4. Deploy backend services.
5. Deploy frontend application assets.
6. Restart or refresh required application services.
7. Execute production health checks.
8. Execute smoke-test scenarios.
9. Open the service to approved users.
10. Observe logs, errors, response times, and registration transactions during the heightened monitoring period.

Production Smoke Tests

• SM-01: authenticated test student can sign in.
• SM-02: active-term course search returns expected records.
• SM-03: test student's current schedule loads.
• SM-04: controlled registration transaction succeeds.
• SM-05: controlled drop transaction succeeds.
• SM-06: registrar test account can access authorized administration pages.
• SM-07: audit events appear for controlled changes.

Rollback Triggers

• Authentication unavailable for a significant portion of users.
• Registration transactions produce incorrect or partial data.
• Unexpected authorization exposure is detected.
• Critical database migration failure occurs.
• Error rate or response time exceeds the agreed emergency threshold and cannot be stabilized quickly.

Rollback Procedure

1. Stop or restrict new registration transactions if required.
2. Notify the incident and release teams.
3. Restore the previous application release.
4. Reverse the database migration only when the approved migration plan confirms reversal is safe; otherwise restore from the approved recovery method.
5. Run previous-version smoke tests.
6. Reopen service when system integrity is confirmed.
7. Document the incident and schedule corrective work.

Deployment Approval

Production release requires approval from the Project Sponsor or delegated release authority, Registrar Business Lead, IT Operations, Technical Lead, and QA Lead.