A Simple Example |
|
|
In this example we will see how Deployment Manager uses the same rules
to deploy changes to a web application and its associated database into three
environments with different structures. Starting with the simplest configuration first, we have a System Test environment which consists of two physical servers; the first serves just the web application and the second just the database. This is defined in Deployment Manager as a logical server which we will call "System Test" and two physical servers, which we will call "stapp" and "stdb". Our deployment will typically consist of a change to the web application, deployed as a complete new WAR file, and a collection of changes to the database, deployed as SQL scripts which we will run against the database. We will also have a small script which applies the SQL scripts to the database according to their naming conventions for ordering and whether they are apply or rollback scripts. To make the deployment we need to drop the WAR file onto the application server and the SQL files onto the database server. We also need to make sure that the database server has the latest copy of the script that applies the SQL files. Three simple rules will allow us to do this:
|
 Selecting servers is very simple with Deployment Manager. We can tag physical servers with their roles, so we simply mark "stapp" with "web=1" and "stdb" with "sql=1". Using a single condition to wrap the deployment action we can now say "deploy *.war to all the servers where web=1". Similarly for "*.sql to all servers where sql=1". Deploying the SQL apply script is only marginally more difficult. Whereas the normal deployments take the latest versions from either the state or the selected packages, with the script we will want to use the latest version from the production state of a separate project. Deployment Manager lets us do this simply by filling in two more fields in the wizard. The final step is to run the SQL apply script (the WAR file in this example takes care of itself). We use the same logic as the deployment, but instead tell Deployment Manager to run the script on all the servers where "sql=1" instead. |
Changing The Structure |
|
Now that we have deployed our application successfully, we want to deploy it
for other stages in the development lifecycle. We might have an Integration
Test environment which consists of a single server running both the web
application and the database. The simplest way to model this is to define two
physical servers which represent partitions of the same machine. Each
partition can then have a different base directory on the same host. If the
structure ever changes, then it is incredibly simple to either change the base
directory or even move that part of the application to another server. |
That's the simple environments out of the way, but what about our production
environment? This has a load-balanced application server and we need to deploy
the WAR file to both servers simultaneously. This is as simple as adding a
third physical server definition for the additional application server and
tagging it with "web=1".
|
Taking It Further |
|
|
Once we have a working deployment set up, we can add additional functionality.
First of all we will want to secure our production environment so that only
privileged users can deploy to it. This just requires us to specify a user
group against the environment to which the user must belong. We can also add some error handling. One simple sanity check we can perform is to deploy pre-requistites like the SQL apply script first, and only if this has succeeded do we attempt to deploy the SQL scripts. This is quite simple to do. |
Finally we might add some parallel test environments. You might have two complete test rigs setup and want the user to choose which rig to deploy to. By defining the second test rig as a new environment and associating it with the same lifecycle state as the first, when the users runs the deployment, the Deployment Manager dialog will off a choice of which environment to deploy to. You can even have different access control policies for the two environments, so that one may be used only by a subset of the users. |
Products
The building blocks of
your integrated solution.
Downloads
