Let's first think about the requirements. What do you expect from deployment automation? You can define high level needs first and then drill down to more specific features. Based on these requirements you can look for available tools in the market or define the architectural framework for a bespoke solution.The following business needs are common for deployment automation:
- Reduce the time to deploy applications
- Prevent application errors due to human mistakes
- Making sure that all deployment steps are performed
- Provide reliable & auditable configuration management
- Knowing who changed what in which environment at what moment
These can be extended with the following required features:
- Role based access control
- Email notification
- Reporting/Change management
- List of required/supported interfaces (WebSphere Application Server, tomcat, IHS, DB, MQ, Oracle, ssh/scp, ANT,...)
Following the requirements, a GAP analysis to determine whether or not a product or custom solution is the best choice. Ultimately, this is input for the business case which should discuss the benefits and costs of deployment automation in your organization. (Don't forget that automating a deployment, requires time to automate the deployment. This overhead is small when multiple environments and multiple deployments are in scope, but high when only one environment is used and deployment steps continuously change.)
Common products in this area (that I know of) are: IBM Rational Automation Framework for WebSphere, WebSphere Cloudburst Appliance, BMC BladeLogic Application Release Automation, XebiaLabs DeployIT.
Most companies that I know of have several parts of the deployment process that do not fit in these tools. So in order to take care of these additional steps, custom scripting is required. Most of the commercial products have the ability to extend their standard functionality by adding custom pre and post deployment tasks or to extend the product API's. This can lead to complex situations.For this reason, most companies today are still deploying their applications manually or using a custom project specific scripting framework. Personally I don't think this is a big problem as long as you create a flexible deployment automation framework that is able to run on the platforms of your choice and are able to perform deployments for all applications within your company.So a framework which is extensible in the deployment targets it supports and the projects and environments it supports.