![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Integrating and Releasing Systems Once you have developed your individual code, it is time to integrate it with other subsystems. When the integration is complete, you can create a system release that can be sent to your customer(s). Patch releases are created to handle special cases that arise during integration and release.
About This Chapter
The major topics covered in this chapter are:
Integration StrategiesWhen multiple developers are working in parallel on a system, there comes a time when the changes that they have been making must be brought together and the result run as a whole. Prior to these times, it is desirable to insulate the developers from each other's changes so that individual tasks can be completed without interference from unrelated tasks. Preventing such interference is one of the reasons for creating a full or partial system configuration for each developer or for each task.
Integration System Configuration
A common integration strategy is to have an integration system configuration. When developers are ready to release certain sets of changes, they update the integration system configuration with those changes. Then, the integration system configuration serves as a common base from which to do system builds. The system build itself may be done in a different system configuration from the integration system configuration because developers can update the integration system configuration at any time, and engineers doing the system builds require stability during the build process. This situation is illustrated in Figure 20.
Figure 20 System Builds with Different System Configurations
![]()
After a build has been completed, developers will want to update their personal system configurations to be up-to-date with respect to the last system build that is considered acceptable.
Creating an Integration System Configuration
An integration system configuration can be created simply by copying any other system configuration. It does not have to have any special properties.
Apex/Summit
In the avionics example system, there is a discussion of creating system configurations by using File > Copy Object and entering the names of the views of the system configuration to copy and the name of the new int.1.wrk system configuration.
This is a case where you have no need for the object files because you will probably not be doing compilation in this system configuration. To avoid copying object files, click Recompile to State and set the option menu to Archived.
System Configuration-System Configuration Updates
Apex/Summit
To update one system configuration from another, follow these steps. (In this example, you will update the int.1.wrk system configuration from the dev.1.wrk system configuration. This procedure updates the destination system configuration (int.1.wrk) so that any units or files in the source system configuration (dev.1.wrk) that are new or are at a higher version than the version in the destination system configuration will be updated. Units or files that are newer in the destination system configuration than in the source system configuration will not be affected.)
- 1 . First check in any units and files that have been modified.
The system configuration-system configuration update only applies to controlled and checked-in units or files.
- 2 . Choose Control > Update Objects.
- 3 . In the Views text entry field enter: /projects/avionics/*/*.ss/dev.1.wrk.
- 4 . Click Add.
- 5 . Click the Accept newer versions into views below button.
- 6 . In the Source or Destination Views text entry field, at the bottom of the dialog box, enter:
/projects/avionics/*/*.ss/int.1.wrk- 7 . Click Add.
- 8 . Click OK or Apply to update the int.1.wrk system configuration.
Updating Specific Objects
Apex/Summit
If specific objects rather than entire views are to be updated, use Control > Update Objects. For example, if the object trig_functions.2.ada (Ada) or trig_functions.C (C/C++) in math_library.ss/dev.1.wrk has been changed and this object is to be "released" for integration, follow these steps:
- 1 . From a directory viewer on math_library.ss/dev.1.wrk, select trig_functions.2.ada (Ada) or trig_functions.C (C/C++) and choose Control > Update Objects.
In the resulting Update Objects dialog box, the selected object appears in the source objects area.
- 2 . Click the Accept newer version into views below radio button.
- 3 . In the text entry field for the Views list at the bottom of the dialog box, enter the name of the destination view, (int.1.wrk) and click Add.
A good way to do this is to click the right mouse button on the completion icon to get a pop-up menu of all of the possible view names. Then click on int.1.wrk.
- 4 . Click OK or Apply to update the trig_functions.2.ada (Ada) or trig_functions.C (C/C++) object in int.1.wrk.
Propagating Import Changes (Apex/Summit)
When a system is under development, there may be a number of changes and reorganizations of the architecture. As a result, the import structure may change. It is possible to update the imports of a view as part of the Control > Update Objects operation.
When imports of a view are updated, the imports of the destination view are replaced by a (possibly modified) copy of the imports of the source view. The imports can be modified by making them relative to the destination system configuration, similar to what is done when a system configuration is copied by File > Copy Object.
To update the imports of a system configuration as part of accepting newer versions of objects, use the following steps. Here you will update the development system configuration rev.1.wrk from the baseline system configuration stable.1.rel, including updating imports.
- 1 . Click on Control > Update Objects to bring up the Update Objects dialog box.
- 2 . Add /projects/avionics/*/*.ss/rev.1.wrk to the Views list. Remove any other objects that may have been listed when the dialog started by selecting them and clicking Remove.
- 3 . Click on the Accept newer version from views below radio button.
- 4 . Add /projects/avionics/*/*.ss/stable.1.rel to the Source or Destination Views list at the bottom of the dialog box.
- 5 . In the Copy Imports area, click on the Add new imports from source views radio button. This will accept the imports from the stable.1.rel system configuration and make them relative to the rev.1.wrk system configuration.
- 6 . Click OK or Apply to accept the updated objects and imports.
Software Release StrategyConstructing a release of a system is the process of building the various pieces that comprise it. Since the pieces can be built in any system configuration, Apex does not require that a special system configuration be built for a release. Often, though, there is a desire to retain releases for some time and to make sure they are not modified after they are built.
Informal releases can be built anywhere. In a project where frequent releases are built so that integration and testing are done on a continuous basis, there might have a simple process whereby a release system configuration exists and is reused for each release. The releases are not retained. The release system configuration can consist of Apex/Summit working views or Rational subsystems and, as needed, some development work to get a release to work properly might be done in the release system configuration. This approach is illustrated in Figure 21.
Figure 21 Personal, Development, Integration, Baseline, & Release System Configs
![]()
Apex/Summit
To build more formal releases that might be retained, numbered release system configurations can be built. For each release, a new system configuration is created and the name of that system configuration in some ways identifies the release. There are three kinds of release system configurations views:
- Development: Unit or file versions and imports can be changed, and compilation can be performed. Units and files cannot be checked out or in.
- Stable: The contents of the units or files cannot be changed. The versions are set. Imports can still be changed.
- Frozen: All properties of the view are frozen.
Creating a Release System Configuration (Apex/Summit)
To create a release system configuration, use File > Copy Object In this example, you create a system configuration called avionics.1.2.3.rel to represent release 1.2.3 of the avionics system:
- 1 . Choose the File > Copy Object command
- 2 . In the resulting Copy Object dialog box, click on the Copy Views radio button.
- 3 . Enter /projects/avionics/*/*.ss/int.1.wrk in the Copy Objects list text entry field and click Add.
If there were any other objects in the list, first remove them by selecting them and clicking Remove.
- 4 . In the Destination area Name field, enter avionics.1.2.3.rel.
- 5 . In the Options area, set the New View Kind menu option to Development.
- 6 . Some View Copy Options to consider:
- a .
If you know that extensive recompilation will be done and that there are object files in the views being copied (int.1.wrk in this case), consider not copying the object files by checking the Recompile to State checkbox and setting the option menu to Archived.- b .
If lots of storage will be used, consider where the storage should go and perhaps click the Place Storage In radio button and enter a directory on the desired file system.- c .
If the model is going to be changed for some reason, check the New Model checkbox and fill in the New Model name.- 7 . Click OK or Apply to construct the new system configuration.
Freezing a Release System Configuration (Apex/Summit)
Sometime after the avionics.1.2.3.rel system configuration is built and compilation and testing performed, the decision will be made that the contents of the system configuration are what is desired for this release. Making the system configuration stable prevents the view contents from being further changed. Follow these steps:
- 1 . Choose Control > Change View Properties.
- 2 . In the resulting dialog box, enter /projects/avionics/*/*.ss/avionics.1.2.3.rel in the Change Properties of Views text entry field and click Add.
- 3 . In the Change Release Kind field, enter Stable. This is most easily done from the alternatives pop-up menu button. Make sure the Change Release Kind check box is checked.
- 4 . Click OK or Apply to freeze the contents of the system configuration.
In this example, you are probably ready to make the release Frozen. In other scenarios, you may still want to recompile or link the system configuration against different imports. This can still be done in a Stable release view. Once Frozen, the imports cannot be changed.
To freeze the system configuration, follow the steps above but set the Change Release Kind field to Frozen instead of Stable.
Deleting a System Configuration
To delete a system configuration, simply delete each of the library contexts in the system configuration. Be careful because uncontrolled files in the system configuration cannot be recovered by Apex, and properties of the library contexts such as their imports and the specifics of the set of versions of objects they contain also cannot be recovered by Apex.
Apex/Summit
To delete the phil.1.wrk system configuration of the avionics system in this example:
- 1 . Choose File > Delete Object
.This brings up the Delete Object dialog box.
- 2 . In the list field text entry field type /projects/avionics/*/*.ss/phil.1.wrk and click Add.
- 3 . Check the Delete nonempty directories check box.
- 4 . Click OK or Apply to delete the system configuration.
Patch ReleasesSince any software system may have bugs, it may become necessary to build a release that fixes a specific problem or set of problems but has no other changes in it. Such a release is called a patch release and is illustrated in Figure 22.
Figure 22 Patch Release System Configurations
![]()
There are several problems to be solved in building a patch release:
- A development area and a release area need to be created to make the changes, compile and test them, and then the release needs to be built.
- The changes to be included may be in files that have since had other changes made to them, and these other changes are not desired in the patch release.
The development process will proceed as follows:
- 1 . A system configuration of Apex working views (Apex/Summit) or Rational subsystems (Apex/ClearCase) will be constructed by copying the library contexts from the release to be patched.
This new system configuration will have the same contents as the release.
- 2 . Changes can be developed in the new system configuration and compiled and linked.
- 3 . When the changes are ready, release views (Apex/Summit) or Rational subsystems (Apex/ClearCase) are created from the working views (Apex/Summit) or Rational subsystes (Apex/ClearCase). The name of the library contexts is the name of the patch release.
- 4 . The system configuration of working views (Apex/Summit) or Rational subsystems (Apex/ClearCase) can be discarded once the release is completed.
Example (Apex/Summit)
Suppose you have an avionics_rel_1.2.3 system configuration that has been shipped. Sometime later, while development is proceeding on the next major release of the system, the need arises to make a patch release for customers using Rev_1.2.3.rel. The patch release will be called Rev_1.2.3a. Suppose there are two subsystems with changes required: rudder and math_library. To begin, a working system configuration needs to be created from the release system configuration. The working system configuration will be called Rev_1.2.3a.
To construct the system configuration:
- 1 . Select the File > Copy Object command
- 2 . In the resulting dialog box, click the Copy Views radio button.
- 3 . In the text entry field of the Copy Views list, enter /projects/avionics/*/*.ss/avionics.1.2.3.rel and click Add.
- 4 . In the Name field in the Destination area, enter avionics.1.2.3a.wrk.
- 5 . In the Options area, set the New View Kind option menu to Working.
- 6 . Click OK or Apply to create the new system configuration.
Next, the development work is done in the new Rev_1.2.3a.wrk system configuration. Editing and version problems may arise. Suppose in math_library.ss, a change is needed in trig_functions.2.ada (Ada) or trig_functions.C (C/C++). There are three possibilities:
- trig_functions.2.ada (Ada) or trig_functions.C (C/C++) has not been modified since the 1.2.3 release.
This case is easy to deal with: the file out is checked out and the changes are made in the Rev_1.2.3a.wrk view. Then the file is checked in.
- trig_functions.2.ada (Ada) or trig_functions.C (C/C++) has been modified, but the only changes are those that are desired in release 1.2.3a.
This case is also easy to deal with. trig_functions.2.ada (Ada) or trig_functions.C (C/C++) in the Rev_1.2.3a.wrk view is simply updated to be the latest version.
- trig_functions.2.ada (Ada) or trig_functions.C (C/C++) has been modified since the 1.2.3 release, and there are changes in it that should not to go into the 1.2.3a release.
This case is more difficult to deal with because trig_functions.2.ada (Ada) or trig_functions.C (C/C++) cannot be updated to be the latest version. There are two ways of dealing with this problem.
- a .
Alternative #1: Create a discontinuity in the version sequence.The principle here is to remember what the latest version number of the file currently is, check out the version in Rev_1.2.3a.wrk (e.g., version 17), and keep the current contents. This creates a latest version that is equal to the version in the Rev_1.2.3.rel release. The changes are made and the file is checked in (e.g., version 18 and 19). The fix is now in Rev_1.2.3a.wrk. Then, in another view, the version for trig_functions.2.ada (Ada) or trig_functions.C (C/C++) is set to what the latest version was before the last changes were started (for example., version 17). That version is checked out, keeping the current contents of the file. The unchanged file is checked in (for example, version 20). This restores the latest version to what it was. If the change going into the patch release is also to go into the main development path, that change needs to be edited back into the latest version as illustrated in Figure 23.
Figure 23 Version sequence of trig_functions.2.ada or trig_functions.C
![]()
- b .
Alternative #2: Change the file's history.The principle here is to sever the development of the affected file so that the main development (in dev.2.wrk, for example) has its latest version and continues unaffected, and the patch release (Rev_1.2.3a.wrk) has an unrelated history for the affected file and can have a different latest version in its own history. Both can then be checked out and changes cannot be propagated between the views for that file.
Compilation, linking, and debugging can be done in the normal way in the Rev_1.2.3a.wrk system configuration. When development and testing in the Rev_1.2.3a.wrk system configuration is completed, the release system configuration Rev_1.2.3a.rel is constructed using the steps outlined in a previous section. Changing the file's history is described in detail in Patch Releases.
Example (Apex/ClearCase)
Suppose you have an avionics_rel_1.2.3 system configuration that has been shipped. Sometime later, while development is proceeding on the next major release of the system, the need arises to make a patch release for customers using Rev_1.2.3.rel. The patch release will be called Rev_1.2.3a. Suppose there are two subsystems with changes required: rudder and math_library. To begin, a working system configuration needs to be created from the release system configuration. The working system configuration will be called Rev_1.2.3a.
Next, the development work is done in the new Rev_1.2.3a system configuration. Editing and version problems may arise. Suppose in math_library, a change is needed in trig_functions.2.ada. There are three possibilities:
- trig_functions.2.ada has not been modified since the 1.2.3 release.
This case is easy to deal with: the file out is checked out and the changes are made in the Rev_1.2.3a Rational subsystem. Then the file is checked in.
- trig_functions.2.ada has been modified, but the only changes are those that are desired in release 1.2.3a.
This case is also easy to deal with. trig_functions.2.ada in the Rev_1.2.3a Rational subsystem is simply updated to be the latest version.
- trig_functions.2.ada has been modified since the 1.2.3 release, and there are changes in it that should not to go into the 1.2.3a release.
This case is more difficult to deal with because trig_functions.2.ada (Ada) or trig_functions.C (C/C++) cannot be updated to be the latest version. There are two ways of dealing with this problem.
Constructing Patch Releases with Partial System Configurations (Apex/Summit)
It may not be necessary to construct complete patch development system configurations or patch release system configurations. Release views or Rational subsystems may be made of only the subsystems that have actual changes. The possibility of doing this depends on the changes.
A minimal system configuration containing only views of subsystems with actual changes can be used if:
- The changes to be made are all implementation changes and do not require changes to program unit specifications (Ada) or header files (C/C++)
- There are program unit specification (Ada) or header file (C/C++) changes but the specific changes are only referenced in the subsystem containing the program unit specifications (Ada) or header files (C/C++)
The reason for these restrictions is that recompilation is necessary only in views that exist in the partial system configuration. If a change does not meet these restrictions, files that are clients of the changed specs must also be recompiled and the partial system configuration must contain views for any subsystems in which they appear.
Patch Release with Minimal System Configuration (Apex/Summit)
Suppose the Rev_1.2.3a release does meet the above restrictions and the patch release can be built of only those Apex/Summit views containing the actual changes. The patch release with a minimal system configuration would be constructed.
Suppose there are two subsystems with changes required: rudder and math_library. New views need to be built for these two subsystems and the executable view where the executable files are linked. The desired import structure is shown in Figure 24.
Figure 24 Minimal System Configuration Patch Release
![]()
Apex/Summit
- 1 . Choose File > Copy Object.
- 2 . In the resulting dialog box, click the Copy Views radio button.
- 3 . In the text entry field of the Copy Views list, enter /projects/avionics/flight_control/rudder.ss/Rev_1.2.3.rel and click Add.
- 4 . In the Name field in the Destination area, enter Rev_1.2.3a.wrk.
- 5 . In the Options area, set the New View Kind option menu to Working.
- 6 . Click OK or Apply to create the three new views.
/projects/avionics/navigation/math_library.ss/Rev_.1.2.3.rel and /projects/avionics/control/executables.ss/Rev.1.2.3.rel.
Note: This is an example of where using dialog history by typing Control-p or clicking on the History Icon is helpful in entering the similar names, and for retrieving the values of other fields of the dialog.
The executions of the copies MUST BE DONE INDIVIDUALLY in this case, otherwise the proper import relationships will not be maintained.
Editing, compilation, and linking is then done in the Rev_1.2.3a system configuration. When linking is done, a configuration file must be used that lists Rev_1.2.3 except for the three views in the Rev_1.2.3a. system configuration. This results in building a system with all of the 1.2.3 code except when there is a 1.2.3a view.
The Rev_1.2.3a release system configuration can be built by copying the Rev_1.2.3 system configuration. Only the three views that were created in the Rev_1.2.3a system configuration will exist in the release system configuration.
Patch Release with System Configuration Slice (Apex/Summit)
If a program unit specification (Ada) or header file (C/C++) in a system is to be changed as part of a patch release and the change does not meet the criterion outlined above, the patch release system configuration needs to include views for all subsystems above the lowest point in the hierarchy where there is a change. (In theory, it really only needs views for subsystems that contain references to specifications (Ada) or header files (C/C++) that are actually changed, but for simplification, assume this is true of all subsystems in the hierarchy above the subsystem containing the changed spec or file.) This situation is illustrated in Figure 25.
Figure 25 Patch Release Import Structure When Spec Change Is Present
![]()
Suppose there are two subsystems with changes required: rudder and math_library. Also suppose that there is a spec change in rudder that affects code in engine_displays.ss. You will need to build new views of these three subsystems, and a view of executable where the executable files are linked.
- 1 . Choose File > Copy Object.
- 2 . In the resulting dialog box, click the Copy Views radio button.
- 3 . In the text entry field of the Copy Views list, enter /projects/avionics/flight_control/rudder.ss/Rev_1.2.3.rel and click Add.
/projects/avionics/navigation/math_library.ss/Rev_.1.2.3.rel,/projects/avionics/control/executables.ss/Rev_.1.2.3.rel, and /projects/avionics/flight_control/rudder.ss/Rev_.1.2.3.rel.
- 4 . In the Name field in the Destination area, enter avionics.1.2.3a.wrk.
- 5 . In the Options area, set the New View Kind option menu to Working.
- 6 . Click OK or Apply to create the four new views.
Development and release then proceeds as in the previous case.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |