Upgrading to a New Release › Considerations for Supporting Generated Applications › Options for Application Upgrade

Options for Application Upgrade

If you have a production application that is built with an earlier version of CA Gen, upgrading your development environment does not directly affect the application's operation. Since most applications require ongoing maintenance to adjust for environment and business changes, consider the effect on the overall application of regenerating part of the application.

The goal of model-based development is to define applicable functional requirements, regardless of programming language or platform. Ideally, a regenerated part would fit seamlessly into an existing application. However, the continuing evolution of the technical infrastructure for CA Gen, compilers, teleprocessing monitors, and operating systems means that you still test and adapt as you move forward.

There are several approaches for maintaining systems that are generated under an earlier version of CA Gen:

• Continue support for the model using your current version of the software.
• Not upgrading the software avoids transition planning and is appropriate when you are likely to drop or replace the system soon.
• Upgrade the system as part of a systems development project.

  If you plan a major modification or extension of the system, you can use the development project as a vehicle for moving toward the current release. During the transition period, implement coordination procedures to ensure that emergency production fixes are also implemented in the new development model, as applicable.

  If you are working with consecutive releases using the same encyclopedia data tables, you can work with separate models using different software, and can migrate required changes forward.

• Convert the model to the current schema and regenerate the entire system in the current release.

  This option requires regeneration of the entire system using the current release code generator and runtime routines.

  The decision to take this option depends on:

  • Availability of regression tools or resources to carry out any system test and regression test activities required
  • System size, complexity, and the impact of system down time on the business
  • During the test period for the newly generated system, fixes required using the earlier version of the model. You must have a coordination procedure to ensure that fixes are not lost during the transition.

  The benefit of this approach is that you can trace all code behaviors to one code generator. It is easier to exploit possibilities for performance improvements that are offered with the newest releases of CA Gen progressively.

• Evolve support for new releases.

  Using this option, the application remains as it is. The model on which it is based resides in the current release encyclopedia and is converted to the current schema. You generate changes to the system as needed, using the current code generator. You include any adaptation that is required for the current release, or other technical environment changes, in tests for the changed portions of the application.

  You plan some code generation testing during the upgrade to establish a level of confidence with the new code generator in your environment and to anticipate adaptation requirements.

  This approach depends on some level of compatibility in runtime support between the prior and current release in the targeted configuration for the generated application. For information about the requirements to migrate to the new release, see the Release Notes.