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 AnthillPro 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, AnthillPro 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.
AnthillPro 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 AnthillPro (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 (Build Life) to the QA environment follows a very different process. The development lead decides what build (Build Life) 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 (Build Life) is to be actually deployed in the QA environment. This way, if the QA team is not ready to receive the new build (Build Life) one will not be forced on them.
These types of hand-offs are explicitly supported by AnthillPro using manual tasks. Chris would configure two additional workflows for the project in AnthillPro, 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 Build Life that is ready to be promoted to QA. This workflow would create a manual task for the QA Manager role in AnthillPro. Upon affirmative completion of this task, AnthillPro would run the Promotion-Approve Workflow on the Build Life. The Promotion-Approve Workflow would be responsible for orchestrating all the activities and jobs required to promote the Build Life and install the application in the new environment. The same two workflows would be used to promote the Build Life from the QA to the UAT environment; only the target server group would change.
The QA team requires that all builds (Build Lives) 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 (Build Life) 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 Build Life. This way, during the first stage of the Build Life (the build), the Dev Stamp Style is used to generate the identifier. Later, during the stage when the Build Life gets promoted to QA, the QA Stamp Style is used to generate a new identifier, guaranteeing that the QA team sees builds (Build Lives) with successive identifiers.
Related posts: