Title by Steve Donie, my former colleague and sensei for all things related to Continuous Integration and Configuration Management.
I'm suggesting to my client that they need to invest in some CI infrastructure for the remainder of their code. They're all in favor, and they want to do it, but it's not a priority because the have "too much sh**" to do. That's understandable, but it's a self-defeating attitude. In my client's case, I think a little CI with some smoke tests may be low-hanging fruit.
Granted I've got a lot of CI experience by now, but I really don't think it should take you more than a couple of man days to set up CruiseControl.Net or something similar. Compare that to the potential loss of time resulting from, for example, a new JAXB mapping gets checked in that breaks a service downstream or database schema changes not getting propagated to all of the development and testing database installations. How much manpower is lost because of those problems? Those very problems can be stopped in their tracks by a good CI infrastructure and philosophy (meaning that somebody has to watch the builds and care when they are broken).
Developers aren't omniscient (sorry). You can minimize the pain through good coding structure, but changing existing code always presents the opportunity to break something else. That something else might not be detectable from mere code inspection. It's a good, good thing to have the CI safety net to detect problems automatically.
Automate anything that moves! Any code, or configuration, or database change that happens repeatedly with anything resembling regularity should be automated. When you're tallying up the cost versus benefit of writing Ant/NAnt/Rake scripts, you absolutely must include the cost of productivity due to screwing up manual activities. When you do that, you might just put a little more value into the build automation.
Granted, a nightly/daily build beats nothing hands down. That being said, the great advantage of full blown CI, with the philosophy of checking in code often, is creating a record of causality between a build breaking and the new code that broke it. Small frequent check in's both lessen the chance of breaking a build by making smaller changes at any one time and ease the burden of diagnosing build or code problems by immediately pointing to the last check in (readily available on the CruiseControl.Net build page).
A lot of the blame has to fall on management's shoulders (and I'm not thinking of anybody in specific here), because they often don't understand or believe the opportunity to go faster by tightening up build or test automation. I don't know how you get around the "management won't let me do the smart thing" issue. The best I can say is to do the things that will make you faster when you need them and not even tell management. As long as you really are making yourself faster, and that's the rub, you should come out ahead. If things are bad, just buckling down to work harder probably isn't going to help matters.