Figure 3 shows a possible setup of the satellite environment. In the example, the development environment, which includes the Control Center, the DB2 control server and satellite control database, as well as the model office and test satellites, is almost entirely separate from the production environment. You use the development environment to both create and test the batches that you want the production satellites to execute.
Figure 3. Satellite Environment
|
In Figure 3, all the production satellites in the production environment belong to the same group, but belong to different subgroups. You can specify that a satellite belongs to a specific subgroup when you either create or edit the satellite with the Satellite Administration Center. You can use subgroups to stage the deployment of the first version of the end-user application.
When rolling out the first version of the end-user application, you stage the deployment to control which satellites can synchronize (that is, which satellites can execute the group batches). You also stage the deployment to test whether the database definition and data is appropriate for the end-user application in the production environment. While the group batches may produce correct results on the model office and test satellites of the development environment, the active data of the production environment may indicate that the group batches have to be modified. For example, in Figure 3, the subgroup Beta 1 is the first stage of the deployment, that is, only the Beta 1 subgroup can synchronize with the DB2 control server. Assume that you receive reports from the Beta 1 users that the performance of the end-user application is not satisfactory. You can address the application-performance problem, then, when the problem is resolved for the Beta 1 subgroup, continue by rolling out the Beta 2 subgroup. Because the Beta 1 and Beta 2 subgroups are running the same version of the end-user application, they execute the same group batches of the same application version. This means that the Beta 2 subgroup is not likely to report the same problem as the Beta 1 subgroup. To stage the deployment of the first version of the application by subgroups, you enable the satellites, subgroup by subgroup, to execute the group batches.
You can also use subgroups to stage the deployment of the next version of the end-user application. For example, assume that the Beta 2 and West Coast subgroups are running the first version of the end-user application, and that you have tested the second version of the application on a model office or test satellite, then installed the new version of the application on the Beta 1 subgroup. In this situation, all the subgroups will be enabled to synchronize, and all will be maintaining active data. The difference is that when the Beta 1 subgroup synchronizes, it executes the group batches associated with the second application version, while Beta 2 and West Coast execute the group batches of the first application version. In this situation, you can use the Beta 1 subgroup both to determine whether the new version of the end-user application is appropriate for your business requirements in the production environment, and whether the group batches that the Beta 1 subgroup executes produce satisfactory results.
[ Top of Page ]