 <p>This sounds very similar to the problem we faced when starting out. The foundation we laid down when building out the QA team still exists today and is a keystone to the success of the release process.</p> <p>Some high level points on how we structure build release</p> <ul> <li><p>We must, at all times, know what is going in to the code and why. Track intent for changes in a bug tracking system of some sort.</p></li> <li><p>All code check-ins must reference a committed set of work. If it's a QOL enhancement, someone creates a ticket t reference. No unreferenced check-in's!</p></li> <li><p>Code is built from scratch at least once a day, multiple times a day is preferable. QA <strong>always</strong> tests from the latest build. </p></li> <li><p>Build failures are treated with the utmost urgency; fixed immediately.</p></li> <li><p>Builds must be stored on long-term storage of some sort, and used as a basis for delivery. Major milestones are tagged not only on source control but on the long-term storage machine. We use a machine called <em>BuildManager</em> for this purpose</p></li> <li><p>I personally do not believe in separating deployment from the QA team. I believe that each QA Engineer should know how to deploy the application and create necessary test data themselves. There are some trade-offs to this approach, I'm happy to discuss them further if interested</p></li> <li><p>Once code is deployed, a sanity test of some sort must be run. Whether it's a systems/configuration test, or an actual functional verification, you must do whatever you can to ensure this build is not going to waste anyone's time. Reducing the wall time between code check-in and knowing there's a solid build in place is one of the best automation investments you can make.</p></li> </ul> <p>From here, how QA is structured and how they work with other members of the team are as critical as the foundation just discussed.</p>