Columbia Games · CCM v2 / August 2026 26.
A CCM deploy should not restart everything just because there was a commit
The production pipeline became migration-aware and incremental: database, runtime, web and SEO changes are detected separately so only the parts that actually need work are rebuilt or refreshed.
Situation
In a large commerce rewrite, the simple strategy of rebuilding and restarting everything after every commit is expensive and creates unnecessary risk. A documentation or frontend-asset change does not justify rebuilding the API image, while a database migration requires an explicit order and a backup. The pipeline was using too little information about the nature of each change.
Approach
I added change detection before deployment and passed explicit flags into the production script describing what had changed. Database migration, API runtime, web publishing and SEO refresh became independent steps that could be enabled only when needed. The detector was deliberately fail-safe: when the system could not classify a change with confidence, it chose the more complete and conservative path rather than risking the omission of a critical step.
Outcome
Releases became faster and had a smaller blast radius. Static changes stopped disturbing the API unnecessarily, while commits containing migrations still received the required database steps and verification every time.