I'm a software developer on a fairly large agile team (we have eight developers actively making changes to a single code repository). Every two weeks, we push a new version of our software to production. Here's our current workflow:
- When starting a new task, developers create a "feature branch" off of the main development branch (we use git) and work off this new branch
- Once a developer has finished work on their task, they merge their feature branch back into the development branch
- The developer merges the development branch into the QA branch.
- A build is triggered off the QA branch. The output of this build is deployed into our QA environment to allow the testers to begin their testing.
It's quite common for our testers to find issues with these new features that have been merged into the QA branch. This means that at any given time, the QA environment likely contains several new features - some tested and bug-free, and some broken. This makes releasing difficult because it's rare that the QA build is in a production-ready state.
To mitigate this, we've been trying to initiate a "QA freeze" which means developers don't merge our development branch into the QA branch a couple days before the release. Bug fixes to the QA environment are made directly on the QA branch and merged down to the development branch. Theoretically, this keeps new, broken features out of QA while still allowing us to fix issues already in QA.
While this "QA freeze" concept has been partially successful, it's hard to coordinate and people are often confused about whether they are allowed to merge to QA. It's also been hard to set a "QA freeze" deadline - everyone likes the idea of some breathing room in between the freeze and the release, but in practice, they'd rather have their feature in the next release than respect the deadline.
Is there a better way to ensure that we have a clean build for our releases every other week?