An anonymous reader writes: My office uses source control and bug tracking systems to develop on 6 week "sprints", on a system with 1 million+ lines of code, that has been in existence for 10+ years. In theory users report bugs, the developers "fix" the bugs, the users test and accept the fix, and finally the "fix" gets released to production as part of a larger change-set. In practice, the bug is reported, the developers implement "a fix", no one else tests it (accept for the developer(s) ), and the "fix" gets released with the larger code change set, to production.
We (the developers) don't want to release "fixes" that users haven't accepted but the code changes often include changes at all levels of the stack (database, DOAs, Business Rules, Webservices and multiple front-ends). Multiple code changes could be occurring in the same areas of code by different developers at the same time making merges of branches very complex and error prone. Many fingers are in the same pie.
Our team size, structure and locations prevent having a single gate keeper for code check-ins. Our development process requires code check-ins to include a "fix" in a test build for our users to test and accept the "fix".
What tools and procedures do you use to prevent un-approved fixes from being deployed to production as part of the larger code change sets?