How Can AnthillPro Help Me Manage My Deployment Process?

Deployment of a real world application is a complex, and all-too-often, a manual process. The complexity comes from the fact that the application may need to be deployed to any number of environments: Development (DEV), Quality Assurance (QA), User Acceptance Testing (UAT), Pre-production (STAGE), and Production (PROD). Each of these environments is typically slightly different requiring different accounts, password, and setting and thus it may seem like manual intervention is required.

Complicating matters is the fact that today's business applications comprise multiple moving parts that all need to be synchronized and deployed together. For example, a typical J2EE application can be made up of an EAR file, database changes, some static content, and environment changes (such as JDBC connection pools, Message Queues, etc.). Making sure that all these pieces get deployed on the correct machines and in the correct order can feel like a daunting task, especially if you need to repeat it for each environment. Keep in mind that each environment may have a different number of database servers, application server, HTTP server, etc.

This type of complex synchronization of activities performed on multiple machines is exactly the type of challenge at which AnthillPro excels. Let's take a look at an example application and see how AnthillPro manages its deployment. This example application is a real world application developed by one of our clients. The entire application lifecycle is managed by AnthillPro, from build management, through deployment management, to release management. The example application is a J2EE application with an EAR file, some static content that needs to be deployed to a separate server, and database changes. The customer has four environments that AnthillPro deploys to: DEV, QA, UAT, and PROD.

During the build, three different types of artifacts are created: artifacts for deploying the EAR file, artifacts for deploying the static content, and artifacts for applying the database changes. When a deployment is kicked-off, AnthillPro creates a task for the DBA to inspect and approve (or reject) the database change script. This to do task is integrated with the customer's internal work-request system. Once the task is created, the DBA can access the task and view the database change scripts. If the DBA approves the scripts (with a simple click of an "approve" button), the deployment proceeds automatically to the DEV environment. AnthillPro concurrently applies the database changes to the Oracle database, deploys the EAR file to the application server, and deploys the static content to the appropriate server. At the end of the deployment, AnthillPro creates a task for the lead developer asking whether a deployment to the QA environment should be performed. When and if the lead developer completes that task in the affirmative, AnthillPro concurrently applies the database changes to the QA instance of Oracle, deploys the EAR file to the QA instance of the application server, and deploys the static content to the QA instance of that server, and then creates a task for the QA manager asking whether the build should be released to the UAT environment. This same process can keep on going until the build reaches production. Keep in mind that at any point, the build can be rejected and thus it will no longer be promoted through the environments.

The above example illustrates a complex and yet automated and repeatable deployment process that is very achievable with AnthillPro. One of the benefits of having a process managed by AnthillPro is auditability and traceability. AnthillPro knows exactly which DBA approved the data base change scripts, which QA manager released the build to UAT, which project manager released the build to Production, and exactly what sources containing what changes made by which developer went into that build.