Promote and Deploy to QA, UAT, PROD Scenario

Chris has been tasked with implementing a process to control the promotion and deployment of application builds. The project for which Chris is implementing this process is a typical three-tiered web application, with some static content to be served by an HTTP server, dynamic content that needs to run on an application server, and a database to store all the data. Chris' organization has four different environments, DEV, QA, UAT, and PROD, that are used as any application goes from development to production. Each environment has a different number of servers dedicated to each role (HTTP, application, and database).

The DEV environment is used by the development team for system integration testing and contains a single server that runs everything. The QA environment is used by the Quality Assurance team to test the application. The UAT environment is where user acceptance testing takes place. In the QA and the UAT environments, there is one HTTP server, one application server, and one database server. The PROD environment is the actual production environment exposed to the world, and contains many load-balanced HTTP servers, a cluster of application servers, and a cluster of database servers.

Because AnthillPro3 uses the concept of Server Groups to model different environments, Chris configures a DEV, a QA, a UAT, and a PROD server group. He can then add the agents running on each of the machines in those environments to the Server Groups. So the DEV server group will end up with a single agent; the QA and UAT server groups will end up with three agents (one for each HTTP server, one for the app server, and one for the database server). The PROD server group may end up with an agent for each HTTP server, each app server, and each database server; however, this does not necessarily have to be the case and will be impacted by factors such as a shared file system for the HTTP server, using an app server-specific deployment manager, etc. When deploying the application to each environment, AnthillPro3 uses server roles to ensure that the appropriate pieces of the application get installed on the corresponding machines.

To complicate matters further, each type of server has different credentials in each of the different environments. So the username and password required to make database changes in the DEV environment is different than that required for the QA environment, the UAT environment, and the PROD environment. The same goes for the HTTP servers and the application servers. This is actually a very big piece, and is required for regulatory compliance. Any solution to this problem must make sure that the credentials for a particular environment are never exposed to an unauthorized user. So a developer that can deploy the application to the DEV environment should not be able to deploy the application to the QA, UAT, or PROD environments; nor should that developer have a way of accessing any of the credentials for the servers in those environments.

AnthillPro3 easily handles this situation. The credentials for servers in each environment can be stored in a secure location and referenced by the Job Configurations in AnthillPro3 (using parameters that are resolved at build-time). The same workflow configuration could be used to deploy the project to each environment, and at build time the workflow would resolve the parameter that returns the name of the server group that is the target of the Workflow Case. Based on this, the proper selection of the credentials can be performed at build time in a secure fashion.

In Chris' organization, any developer may deploy the project to the DEV environment to test changes. But promoting a build (BuildLife) to the QA environment follows a very different process. The development lead decides what build (BuildLife) is ready to be promoted to the QA environment. Then the QA manager is informed and it is up to the QA manager to decide when the new build (BuildLife) is to be actually deployed in the QA environment. This way, if the QA team is not ready to receive the new build (BuildLife) one will not be forced on them.

These types of hand-offs are explicitly supported by AnthillPro3 using manual tasks. Chris would configure two additional workflows for the project in AnthillPro3, a Promotion-Request Workflow and a Promotion-Approve Workflow. The Promotion-Request Workflow is the one that would be invoked by the development lead on a BuildLife that is ready to be promoted to QA. This workflow would create a manual task for the QA Manager role in AnthillPro3. Upon affirmative completion of this task, AnthillPro3 would run the Promotion-Approve Workflow on the BuildLife. The Promotion-Approve Workflow would be responsible for orchestrating all the activities and jobs required to promote the BuildLife and install the application in the new environment. The same two workflows would be used to promote the BuildLife from the QA to the UAT environment; only the target server group would change.

The QA team requires that all builds (BuildLives) delivered to them have successive identifiers. This can be difficult to implement, especially if the development team practices Continuous Integration and generates 10 or more build identifiers per day. The only way to ensure that each build (BuildLife) released to QA has a successive identifier is to generate a new identifier for the QA team. Chris can configure multiple Stamp Styles to support the multiple identifiers being applied to each BuildLife. This way, during the first stage of the BuildLife (the build), the Dev Stamp Style is used to generate the identifier. Later, during the stage when the BuildLife gets promoted to QA, the QA Stamp Style is used to generate a new identifier, guaranteeing that the QA team sees builds (BuildLives) with successive identifiers.

After a month of using AnthillPro3, Chris was given a cape and he then flew off to fight crime.