You should only be doing Continuous Delivery to a development server. Look at deploying changes to an exploded application on this server. If this isn't suitable increase the PermGen size. Schedule daily restarts of the server to clear the memory.

Tag and build a deployment package for the Integration Server and only deploy when requested. This should be co-ordinated with the Integration testing team. I find that more than once a day is usually excessive for this environment.

Deployment of the tested deployment package from the Integration Server to Production should only be done on approval. This usually needs to be scheduled for off-hours.

EDIT: Everywhere I've worked where we had automated deployment it has been hand crafted. There tend to be issues around privileges, approvals, schedules, etc. that might make a generic product not fit well in a particular environment. In environments with multiple load balanced servers, there can be additional issues.

You should only be doing Continuous Delivery to a development server. Look at deploying changes to an exploded application on this server. If this isn't suitable increase the PermGen size. Schedule daily restarts of the server to clear the memory.

Tag and build a deployment package for the Integration Server and only deploy when requested. This should be co-ordinated with the Integration testing team. I find that more than once a day is usually excessive for this environment.

Deployment of the tested deployment package from the Integration Server to Production should only be done on approval. This usually needs to be scheduled for off-hours.

EDIT: Everywhere I've worked where we had automated deployment it has been hand crafted. There tend to be issues around privileges, approvals, schedules, etc. that might make a generic product not fit well in a particular environment. In environments with multiple load balanced servers, there can be additional issues.

EDIT2: I have always advocated automated deployment. Continuous deployment as I have experience it is build and deploy on check-in. You don't want production to be the deploy target. It is a good way to ensure things build in the target environment and not just on the developers desktop.

Picking off builds as deploy candidates for further testing and possible production deployment is not what I would consider continuous deployment. I do consider it a best practice if the selection and migration is automated

You should only be doing Continuous Delivery to a development server. Look at deploying changes to an exploded application on this server. If this isn't suitable increase the PermGen size. Schedule daily restarts of the server to clear the memory.

Tag and build a deployment package for the Integration Server and only deploy when requested. This should be co-ordinated with the Integration testing team. I find that more than once a day is usually excessive for this environment.

Deployment of the tested deployment package from the Integration Server to Production should only be done on approval. This usually needs to be scheduled for off-hours.

You should only be doing Continuous Delivery to a development server. Look at deploying changes to an exploded application on this server. If this isn't suitable increase the PermGen size. Schedule daily restarts of the server to clear the memory.

Tag and build a deployment package for the Integration Server and only deploy when requested. This should be co-ordinated with the Integration testing team. I find that more than once a day is usually excessive for this environment.

Deployment of the tested deployment package from the Integration Server to Production should only be done on approval. This usually needs to be scheduled for off-hours.

EDIT: Everywhere I've worked where we had automated deployment it has been hand crafted. There tend to be issues around privileges, approvals, schedules, etc. that might make a generic product not fit well in a particular environment. In environments with multiple load balanced servers, there can be additional issues.