Creating a new deployment process

The new deployment process has been made public at last. It's difficult to describe what we're doing now, it involves a lot of manual work and as our code sourcing isn't done very well, we often wind up having files forgotten or overwritten with old versions of code. While for a QA person this is a guarantee of long-term employment, in fact, finding the same bugs over and over again is quite dispiriting as it takes away any feeling of accomplishment with releases as it's almost guaranteed that some issue fixed before, and usually several of them, will be cropping up in the new release. We have automated testing, but our code base is so complicated we don't test every little thing with the automation, and growth of our automated code base is oh-so-frequently caused by the discovery of the latest new thing we've managed to break and subsequent addition of an automated check for said bit of code.

The new plan kind of goes like this: first, we get our servers set up; then we have daily automated code drops with some testing and a possible second test server if the code is really unstable; then, in the week that is the release sprint, we merge with any other code waiting to go live and everyone in the team tests like mad (or otherwise works on the release) for the remaining days until we go out.

My problem is this: I don't really see a point at which some time is being scheduled to do end to end testing of the code before we merge with the rest of the code. Also, there just isn't any contingency built in; it's assumed we won't need more time for testing before the merge, and that dumping a pile of bodies on the work will always be sufficient for after the merge and will be enough to guarantee that we'll be able to go live on schedule. Third, we're sticking to our silly, rigid deployment timeline. The teams are being told they pretty much have to release every cycle; the release team is anticipating that the code will be ready like clockwork. There's no wiggle room. And on top of all of this, the attitude is that if you say there are any possible holes in this process you're being negative about the conversion to Agile.

Really, this is quite a time we're having here. I do really hope that the automated build deployment gets up to speed quickly, and that it serves to quickly reduce the amount of problems we have and time we spend working on builds that have old or missing code in them. I still think we'll need to learn how to fit testing into the process better and come up with some more flexibility for our release schedules, but we can only fix one thing at a time, and this one is a biggie. Over time, it's my belief that we won't have to have the whole team drop out during the release, that release tasks can just be part of the next sprint and one or two developers can be on it as necessary and then move on to regular development work along with everything else, but in the beginning it makes sense to have the whole team work on it while we're ironing out the process.