VCS strategy with TeamCity and CI
- by Luke Puplett
I'm planning a strategy which seeks to allow automated deployment of a website codebase into QA and production on check-in. We're using the fabulous TeamCity.
We want to control release to live production; i.e. not have every check-in on Trunk go live.
So my plan is to use Trunk as QA. Committing to Trunk triggers deployment to QA. I will then have a Production branch which also triggers deployment on commit, to the live site.
The idea is simply that Trunk represents the mainline codebase but it hasn't gone live yet. We can branch features and do daily pulls from Trunk into those feature branches as per normal and merge/re-integrate into Trunk when we're happy for it to go to QA.
When the BAs give the nod, we then smash a bottle of champagne and merge Trunk to Production and out she goes.
I've never seen it done like this. Other greenfield CI strategies involve hiding features and code from production via config - this codebase can't cope with that - or just having CI on QA and taking cuts and manually pushing to live.
Does my plan sound alright?