Change Records

1. Overview

A Change Record is a document that logs any change made after deployment to production, including patches, hotfixes, infrastructure updates, or configuration changes.

• There is no need to log changes during development as updates can simply be reflected in the project’s features list.

It helps:

• Ensure traceability and accountability
• Maintain a clear audit trail
• Coordinate between teams

A good Change Record should be:

• Concise - only relevant details
• Informative - purpose, scope, impact
• Chronological - sorted by implementation date
• Actionable - with links to commits, tickets, or related documents

2. Repository Structure

Once an application is deployed to production, the repository must include a change-records/ directory to store all post-production change records.

• Each change should be documented in a separate file, following an append-only approach to ensure traceability.
• We recommend using the Change ID (e.g., 20250514-001) as the filename, as it ensures chronological ordering and uniqueness.
• Note that these change records are only required after production deployment

3. Template

Change ID

The Change ID should be unique and chronologically sortable (YYYYMMDD-NNN):

• e.g., 20250514-001
• Good for multiple changes on the same day

Date of Change

YYYY-MM-DD

Requester

Who requested the change (client name or support team member) Requested by: Name (Role)

Change Owner

Name of the person/team who implemented the change

Change Category

Select one or more (comma-separated):

• Frontend (FE)
• Backend (BE)
• Documentation (ML)
• Infrastructure (Infra)
• Other (specify)

Example: Frontend (FE), Backend (BE)

Change Type

Select one:

• Hotfix
• Patch
• Configuration Update
• Feature Enhancement
• Infrastructure Change
• Security Fix
• Rollback / Revert

Change Description

Brief summary of what was changed and why

Related Tickets/References

Link to:

• GitHub PR
• ClickUp Ticket

Risk Assessment

Select one:

• Standard (routine, low-risk)
• Normal (non-urgent, some risk)
• Emergency (urgent production fix)
• Expedited (business-critical, approval fast-tracked)

Optional explanation (e.g., “affects authentication service for all users”)

Deployment Method

Manual / CI/CD Pipeline

Approval

Approved by: Name (Role)
Approval date: YYYY-MM-DD

Note: here we mean the PM/manager/lead who approved the change.

Rollback Plan

Summary of how to revert the change if needed

Verification & Outcome

How it was verified (tests/logs) and outcome:

• Successful
• Partially Completed
• Failed

Post-Change Notes

Observations, issues, or follow-ups after the change

Note: this section is optional and can be omitted.

4. Example

Refer to file 20250514-001.md.