Purpose
This policy defines the process for managing changes to Carriyo's production systems and infrastructure. It ensures that changes are implemented in a controlled manner, minimizing risk to service availability and security.
Scope
This policy applies to all changes to production systems, including application code, infrastructure configuration, database schemas, network settings, and security controls.
Change Categories
Standard Changes
- Pre-approved, low-risk changes that follow a documented procedure
- Examples: routine dependency updates, minor UI changes, documentation updates
- Approval: automated via CI/CD pipeline checks
Normal Changes
- Changes that require review and approval before implementation
- Examples: new features, significant code changes, infrastructure modifications
- Approval: peer code review + engineering lead approval
Emergency Changes
- Urgent changes required to resolve critical incidents or security vulnerabilities
- Examples: security patches, critical bug fixes, incident remediation
- Approval: security team or CTO, with retrospective review within 48 hours
Change Process
1. Request
- All changes are tracked in our version control system (Git)
- Change requests include: description, risk assessment, rollback plan, and testing evidence
2. Review
- All code changes require at least one peer review
- Security-sensitive changes require security team review
- Infrastructure changes require DevOps team review
3. Testing
- Automated unit and integration tests must pass
- Changes are validated in a staging environment before production deployment
- Performance testing is required for changes that may impact system load
4. Approval
- Changes are approved based on their category and risk level
- Approvals are documented in the version control system
5. Implementation
- Changes are deployed through automated CI/CD pipelines
- Blue-green or rolling deployments minimize service disruption
- Deployment monitoring ensures changes do not degrade performance
6. Verification
- Post-deployment verification confirms the change was successful
- Monitoring systems are checked for anomalies
- Rollback is initiated if issues are detected
Rollback Procedures
All changes must have a documented rollback plan. Automated deployments include rollback capabilities that can be triggered within minutes of detecting an issue.
Audit Trail
All changes are logged with:
- Who requested the change
- Who approved the change
- When the change was implemented
- What was changed
- Why the change was necessary