One of the processes that I was introduced to while working at Apple was CCC: Code Change Control.
During normal development, the requirement for many teams was that your code needed to be reviewed by at least one other developer before you checked it into the main branch.
When we were approaching our product's ship date, the code that was allowed to be submitted was subjected to a much more thorough review and testing process. The goal was to reduce the potential for changes made late in a program to destabilize software prior to release for mass production (for factory software) or GM release (for customer software). If you are approaching a release and need to enforce rigorous validation to ensure quality, the CCC process may be a useful candidate.
The CCC template has these primary goals:
- Make sure you've actually tested the software, publishing your testing details
- Publish the hardware verisons you have tested on
- This could be multiple devices, such as iPad X, iPhone Y/Z
- This could also be a single device, but a specific harware revision, e.g. CoolDevice - DVT build
- Publish the software version you have tested your changes with
- Make sure you're aware of both performance and customer impacts of your change
- Make sure you've had multiple people review your changes
This CCC message would be included in any review requests. Reviewers should audit the CCC details and suggest any additional testing that may be required.
The CCC message should also be included in the commit message, including the reviewers who signed off on the change. By adding the CCC message to the commit message, you provide traceability and a reference for those debugging your changes in the future.
Here's a general CCC template that you can use for your project:
[General change description / commit message goes here] * Hardware Tested On: * Software Revisions Tested On: * How I tested this change: * Customer Impact: * Performance Impact: * Performance Testing Details: Reviewed-by: Reviewed-by: