CM and Agile validation process of merging to the Trunk?

We are a new Agile shop and we are encountering an issue that I hope others have seen.

In our process, the Trunk is considered an integration branch; it does not have to be releasable, but it does have to be stable and functional for others to branch off of. We create Feature branches of the Trunk for new development. All work and testing occurs in these branches. An individual branch pulls up as needed to stay integrated with the Trunk as other features that are accepted and are committed. But now we have numerous feature branches. Each are focused, have a short life cycle, and are pushed to the trunk as they are completed, so we not debating the need for the branches and trying very much to be Agile.

My issue comes in here: I require that the branches pull up from the Trunk at the end of their life cycle and complete the validation, regression testing and handle all configuration issues before pushing to the trunk. Once reintegrated into the Trunk, I ask for at least a build and an automated smoke test. However, I am now getting push back on the Trunk validation. The argument is that the developers can merge the code and not need the QA validation steps because they already complete the work in the feature branch. Therefore, the extra testing is not needed. I have attempted to remind management of the numerous times "brainless" merges have failed. Thier solution is to instead of build and regression testing to have the developer diff the Feature branch and the newly merged Trunk. That process in thier mind would replace the regression testing I asked for. So what do you require when you reintegrate back to the Trunk? What are the issues that we will encounter if we remove this step and replace with the diff? Is the cost of stayi开发者_C百科ng Agile the additional work of the intergration of the branches?

Thanks for any input. LoneCM

I don't see why a "build and automated smoke test" should be any substantial extra work, or be accounted as a "cost of staying Agile" -- given it's all automated, of course. (Indeed I normally would consider a continuous build/integration and automated testing to be part of the set of best practices associated with Agile development). diff in general doesn't cut it as there may be files that will never compare equal (binary resources whose format includes time stamps, for example) and only testing can confirm that the differences, if any, do not impair correctness.

If multiple developers (presumably pairs thereof, if you do pair programming) can all be committing to trunk independently (i.e., no "locking of trunk" allowed), then the kind of minimal sanity check you advocate is highly recommended -- whether the underlying development be "agile", totally chaotic, or whatever else;-).