Application lifecycle management
In Part II, we created the GeneralInsuranceDev platform and the GeneralInsuranceCustomer IBM Customer Information Control System (CICS) Transaction Server (CICS TS) application. In Chapter 4, “Creating an application” on page 51, we saw how, by defining entry points for our application, we can enable application-level monitoring and threshold policies.
In Chapter 5, “Applying a policy” on page 97, we added a new policy to the application and updated its version to 1.0.1, so that new messages emitted as a result of the policy addition could be attributed to the changes in version 1.0.1. Then in Chapter 6, “Packaging an application for multiversion deployment” on page 127, we saw how we could enable multiple versions of the same application to run in the same CICS TS regions at the same time, by defining private CICS TS program and library resources within the application.
We updated the application to version 1.0.2 when we repackaged the applications program and library resources to enable multi-versioning, and then we created version 1.100.0 of the application and deployed it alongside version 1.0.2 on the GeneralInsuranceDev platform.
In this chapter, we describe why we chose the version numbers that we did in Part 2, “How to cloud-enable your IBM CICS TS” on page 23. We discuss semantic versioning, which we suggest for the new cloud resources, and which was used in previous chapters. We examine in more detail the benefits of being able to run multiple versions of an application at the same time, and we discuss how these techniques can be applied to the GeneralInsuranceCustomer application around which we have based our examples.
This chapter provides information about the following topics:
9.1 Managing application change through versioning
Applications evolve in response to business needs. Developers fix bugs, architects design new capabilities, and system programmers use platform enhancements. We need a way of expressing the nature of these changes, in addition to understanding their effect on existing users, applications, and data.
We also need a way to package and manage the lifecycle of these changes, including reverting to a previous version if we encounter problems. We want users of our applications to experience a seamless transition to a new version. We might also want to phase in a new version of an application, enabling a subset of our users to try out the new version before rolling everyone onto it.
9.1.1 Semantic versioning
CICS TS V5.1 introduced a new CICS TS application resource that requires a version and a name. A version must also be specified for a CICS bundle that is to be installed as part of either a CICS TS application or a CICS TS platform. CICS application bindings have a version too. Why is this version needed, and how should you use it?
We need to separate describing what an application does and its name, which does not change, from how well it does it and its version, which does change. We are all familiar
with software product versions, from operating systems and mobile phone applications to CICS TS.
with software product versions, from operating systems and mobile phone applications to CICS TS.
The versioning system suggested for CICS TS cloud enablement, and the one used in this IBM Redbooks publication, is described in the technical white paper Semantic Versioning, by the Open Service Gateway initiative (OSGi Alliance):
It is widely used in OSGi-based projects, such as Eclipse, and was first seen in CICS TS V4.2 with the Java class library for CICS (JCICS) application programming interface (API) in both the CICS Explorer software development kit (SDK) and Java virtual machine (JVM) server run time. It enables the author of an API or service to clearly describe the nature of a change in the implementation, so clients can understand any compatibility issues with earlier versions.
The version attribute used for a CICS TS application, a CICS bundle, or an OSGi bundle takes the form <major>.<minor>.<micro>, for example, 2.3.1. The version should be updated manually by whoever is responsible for maintaining the resource concerned, for example, the application developer. The version should be the first change made as part of a new activity. The version part changes should be used in the following ways:
•Micro, for example, from 1.0.0 to 1.0.1. No external change (for example, a bug fix).
•Minor, for example, from 1.0.1 to 1.100.0. Compatible with an earlier version or an external change (for example, existing clients are unaffected).
|
Note: You might be wondering why we chose to increase the minor version by 100 rather than by 1. This technique is valuable when you want to run multiple versions of the application simultaneously. Imagine a scenario where version 1.0.0 is in production and you add in version 1.1.0. For awhile, both versions run without problems at the same time.
Then, a bug is found in version 1.0.0 that requires a small change to the application externals. Ideally, we would increase the minor version number, because the externals have changed, but V1.1.0 is already being used. If instead we had used version 1.100.0 when we added the new version of the application, we could have fixed the bug in V1.0.0 and increased its minor version number to reflect the fact that a change to the externals of the application was made.
This technique is used by CICS TS to version the OSGi bundles included with the JCICS APIs.
|
•Major, for example, from 1.100.0 to 2.0.0. Change is incompatible with earlier versions (for example, a different file record format, or an operation is removed).
9.1.2 Development lifecycle
The version is also extremely important for change management and problem diagnosis. You might ask the question, “Which version of the GeneralInsuranceCustomer application is running on the GeneralInsuranceTest platform?” You can track changes back through the lifecycle, to a user workspace and eventually to version control (for example, IBM Rational® Team Concert.
The versions of the individual CICS bundles that compose the application are shown in CICS Explorer, and the CICS TS application version is recorded in monitoring data. In Chapter 7, “Measurement by application” on page 175, we show how this can be used to compare the behavior and performance of different versions of the same application.
9.2 Managing application deployment through versioning
CICS TS V5.2 introduces the ability to run multiple versions of the same CICS TS application on the same CICS TS platform (for example, the same set of CICS TS regions). If an Application A defines a CICS TS program called ADD, version 1.0.0 and version 1.0.1 of Application A can each run their own different private version of the ADD program. Deploying multiple application versions was demonstrated in Chapter 6, “Packaging an application for multiversion deployment” on page 127.
This ability to run multiple application versions simultaneously, enables CICS TS applications to be updated with no outage of the application for customers. It enables different users to start different versions of the application, and it makes it simple to switch back to a stable version of an application if a new version turns out to have errors.
9.2.1 Switching application versions with no outage
As demonstrated in Chapter 6, “Packaging an application for multiversion deployment” on page 127, you can now Install, Enable, and Make Available multiple versions of the same application. When CICS TS detects that two or more versions of the same application are Available, it automatically routes requests to the version with the highest version number.
Figure 9-1 demonstrates how EXEC CICS LINK requests to an application entry point program always get routed to the highest available application version. GeneralInsuranceCustomer V1.0.2 is Enabled and Available. GeneralInsuranceCustomer V1.100.0 is ready for deployment. It is Installed and Enabled. At this point, work still flows to V1.0.2. Now V1.100.0 is made Available. New requests flow to V1.100.0, while requests already being processed in V1.0.2 complete in V1.0.2.
Figure 9-1 Linking to an entry point program always picks the highest AVAILABLE application version
If, having made a new version of the application available, you find that there is a problem with it, simply set it to Unavailable.
Figure 9-2 gives an example. GeneralInsuranceCustomer V1.100.0 has a problem. The decision is made to revert to V1.0.2. GeneralInsuranceCustomer V1.100.0 is Made Unavailable. Now, new requests flow to V1.0.2, while requests already being processed in V1.100.0 complete in V1.100.0.
Figure 9-2 Version 1.100.0 is UNAVAILABLE so EXEC CICS LINKs revert to V1.0.2
Whether moving to a new version, or removing a version, the transition occurs without the need for an application outage.
9.2.2 Phasing in a new application
The ability to run multiple versions of the same application in parallel can enable a model whereby a subset of your customers gets to try out the latest version of the application, while the majority continues to use an earlier version. This can be achieved in different ways:
•A router program is in front of your application, and decides which version of the application a particular request should be sent too. It uses a new CICS TS API command, EXEC CICS start APPLICATION, to call an explicit application version. The start APPLICATION command enables the user to specify the target major version and minor version of the application. The latest micro version (bug fix) is always used.
Figure 9-3 shows an example. GeneralInsuranceCustomer V1.100.5 and V1.200.0 are both Enabled and Available. The router program decides that an inbound request should be sent to V1.100. It issues the following command (one line):
EXEC CICS start APPLICATION(GeneralInsuranceCustomer) OPERATION(inquireCustomer) MAJORVERSION(1) MINORVERSION(100) EXACTMATCH
The request is routed to V1.100.5 of the application.
Figure 9-3 A router program explicitly targets a specific application version
•The different versions of the application expose different application entry points, providing external routes into the different versions of the application.
Figure 9-4 shows an example. GeneralInsuranceCustomer V1.300.0 includes a web services front end to the application. A URIMAP resource is defined in the application binding, and is enabled as an application entry point. When inbound Hypertext Transfer Protocol (HTTP) requests match the URIMAP, they are directed into V1.300.0 of the application.
Now a new version, V1.400.0, is deployed. In its application binding, it defines a different URIMAP as its entry point. Both versions of the application can be installed, enabled, and made available at the same time. The web service requester can choose which version of the application they start by altering the Uniform Resource Identifier (URI) that they send the request message to.
Figure 9-4 URIMAP entry points match different web requests, and associate them to an application version
9.2.3 CICS TS region consolidation
Continued improvements to the scalability of CICS TS have enabled customers to consolidate regions, save costs, and minimize the number of CICS TS regions that need to be managed. This can be a challenge, because different applications can use the same CICS TS program names, making it impossible to run both applications on the same CICS TS region without changes.
By packaging these applications as CICS TS applications, you can resolve this problem. CICS TS program and library resources defined within a CICS TS application are considered private to that application. Therefore, different Applications can be installed, enabled, and made available to run on the same CICS TS regions, even if they use the same CICS TS program names.
Figure 9-5 shows an example where Application GeneralInsuranceCustomer V2.0.0 defines a CICS PROGRAM called ADD. The IT department wants to run the GeneralInsuranceCustomer Application on the same CICS TS platform (the same CICS TS regions) as another Application Calculator V1.0.0. The Calculator program also defines a CICS PROGRAM called ADD.
This is acceptable, though. Because the programs are defined as part of CICS TS applications, both can be installed and run at the same time, and each uses its own private copy of PROGRAM ADD. This would not have been possible if the programs were defined in the CICS system definition (CSD).
Figure 9-5 Enabling region consolidation for applications with clashing PROGRAM resources
9.3 Applying versioning to GeneralInsuranceCustomer
In this section, we discuss how semantic versioning can be applied to the GeneralInsuranceCustomer application, both during the application development lifecycle, and the application deployment lifecycle.
9.3.1 Using semantic versioning
In Chapter 4, “Creating an application” on page 51, we created version 1.0.0 of the GeneralInsuranceCustomer application, including version 1.0.0 of all of the CICS bundles that it consists of. In Chapter 5, “Applying a policy” on page 97, we added a new policy to the application, and updated its version to 1.0.1, so that new messages emitted as a result of the policy addition could be attributed to the changes in version 1.0.1.
In Chapter 6, “Packaging an application for multiversion deployment” on page 127, we repackaged the application to define a subset of the resources, to enable multiple versions of the application to be made available at the same time, on the same CICS TS platform. Before making the change, we updated the CICS bundle micro version and the CICS TS application micro version (version 1.0.2).
This is because the changes had no compatibility issues with earlier versions, and no external application changes. For example, a user would see no change in the capability of the application.
We then demonstrated creating a new version of the application to implement a new requirement to protect certain customer data fields from unauthorized users. We updated the application minor and micro version numbers to 1.100.0. This is because the change introduced new functionality, and made a change to the externals of the application, but was compatible with earlier versions.
It is important to track changes through both the development and deployment lifecycles, so that if a problem did occur, it would be possible to trace the change back to the user that made it. For example, suppose that you repackage the GeneralInsuranceApplication as shown in Chapter 6, “Packaging an application for multiversion deployment” on page 127.
If you forgot to discard a LIBRARY resource or remove its definition from the CSD group that is installed at start, there would be a name clash, and the CICS TS application would fail to install completely. Knowing the version of both the CICS TS application and the failing CICS bundle would help to resolve the problem, if you know the changes that have been made in each version.
Another change that would require an update to both the CICS bundle and CICS TS application is a bug fix. Although such a change might not affect the externals, it can affect application behavior. Then, an analysis of any monitoring data can take advantage of the full application name and version.
9.3.2 Semantic versioning in the development lifecycle
Application change is an ongoing process requiring an appropriate update to version information for each separate piece of work. For example, it might not be possible to repackage all resources that make up an application at the same time, due to restrictions in the set of resources that support multiple versions of an application running simultaneously on the same CICS TS platform.
If and when additional resources are supported by CICS TS in a future release, you might want to revisit the application and make changes to it. In each case, the version of the individual CICS bundles and overall CICS TS application must be updated again.
In addition to considering the overall CICS TS application version, changes at the CICS bundle and, if using Java, the OSGi bundle level, can also be determined. This is because the version number is central to the application lifecycle. When assembling an application, the developer chooses the specific version of each CICS bundle used.
9.3.3 Semantic versioning in the deployment lifecycle
When creating a CICS TS application definition, the version of both the CICS TS application and CICS application binding are specified. Finally, when the application is installed, the service provider chooses which versions of the application to make available.
Version information can be extremely helpful when deciding where or whether an application should be deployed after it is promoted through the development lifecycle. The following list describes some examples:
Micro Low risk. Deployment might be allowed or even required outside the normal change window.
Minor Requires regression testing for existing clients, and might require infrastructure change, for example, new platform dependencies.
Major Can require platform separation, for example, data format change.
9.4 Evolving the GeneralInsuranceCustomer application
The GeneralInsuranceCustomer CICS TS application we have used for the examples in this IBM Redbooks publication has a traditional IBM 3270 terminal interface. We could modernize it in an update, introducing a web services interface, a capability that is available in the General Insurance Application (GENAPP). According to the definition we used in 9.1.1, “Semantic versioning” on page 194, this would be a change to the externals, but one that is compatible with earlier versions (existing IBM 3270 clients are unaffected).
There are no changes to the customer records, so there are no compatibility issues for the database (or the Virtual Storage Access Method (VSAM) files). This means that we could deploy the new version onto the same platform as the previous one at the same time if we chose to. If any problems were encountered, the update could be backed out without any risk of data corruption.
To add the web service interface, we would create a new CICS bundle, GeneralInsuranceCustomerPresentationWeb, so that there are no changes to existing bundles, and all updates to the application are kept in one place. This makes it clear when developing, deploying, and managing the application that we are not changing the existing IBM 3270 interface.
In the future, this approach would help us to distinguish between updates made to the IBM 3270 interface and those made to the web services. Also, we could more easily remove the traditional interface in the future if it is no longer required.
The next task would be to determine the new CICS TS application version. The new GeneralInsuranceCustomerPresentationWeb Bundle would have default version 1.0.0, which is acceptable because the bundle is new. We are making a change to the application that is compatible to an earlier version, so we increment the minor version of the application, for example, 1.200.0.
We would also need a Transmission Control Protocol/Internet Protocol (TCP/IP) service. In CICS TS V5.2, we can define TCP/IP services within CICS bundles. However, we might not want to include the TCP/IP service in the application, because TCP/IP services are often resources that are shared by multiple applications. In this case, it makes more sense to define the TCP/IP service as a part of the CICS TS platform, and to assert a dependency on the TCP/IP service in the application.
We could define a new CICS bundle which would be installed into the ApplicationServices region type. This can be added to the GeneralInsuranceDev platform so that when it is next installed, the TCP/IP service is defined. To save having to restart the platform and disrupt any other applications it might be hosting, we could use the technique described in Chapter 5, “Applying a policy” on page 97 to add a CICS bundle to a running platform.
9.5 Promoting GeneralInsuranceCustomer from dev to test
Suppose that unit testing of version 1.200.0 of GeneralInsuranceCustomer, using the single managed region GeneralInsuranceDev platform, is complete. The next step is to promote the application to the GeneralInsuranceTest quality assurance platform for further testing before promotion to production.
This platform is more representative of the production environment in that it has separate regions for the Terminals, ApplicationServices, and DataAccess region types. Deployment to this platform helps ensure that multiregion operation (MRO) is working correctly.
We need to create general.insurance.customer.to.test.platform.binding, a new application binding. The general.insurance.customer.to.dev.platform.binding application binding is similar, in that the GeneralInsuranceTest Platform has the same region types as GeneralInsuranceDev. However, the new application binding gives us the opportunity to manage the application lifecycle differently, and to make certain adjustments to the externals. In particular, we could use a different Uniform Resource Locator (URL) for the web services.
9.6 GeneralInsuranceCustomer deployment lifecycle
In this section, we describe how we could replace the existing GeneralInsuranceCustomer version 1.100.0 with version 1.200.0, and then back out the changes by simply reverting to the previous version. Chapter 4, “Creating an application” on page 51 introduced the application deployment lifecycle. In this section, we expand upon that capability.
You now have the new version 1.200.0 of GeneralInsuranceCustomer, which provides a web services interface. You need to deploy the application, then you can install it, enable it, and make it available to users.
The first step is to export version 1.200.0 of GeneralInsuranceCustomer as originally described in Chapter 4, “Creating an application” on page 51, creating a new APPLDEF in the process. This is a decision point for whoever is deploying the new application version. If, as described in Chapter 6, “Packaging an application for multiversion deployment” on page 127, we have merely implemented an internal structural change reflected in an increase in the micro version (for example, 1.0.2), there should be little risk installing the new version.
However, if we were about to install version 2.0.0 of the application, it would be prudent to disable and discard the old version, and to delete the old APPLDEF. This is because an increase in the major version indicates that we have introduced a change that is not compatible with an earlier version of the application, including perhaps a change in record formats. Removing the old application version prevents possible corruption to the database.
In this example, an increase in the minor version indicates a change in the application that is compatible with an earlier version. There are new externals to test, and new dependencies on the platform that must be validated, but it should be safe to revert to the previous version
if necessary.
if necessary.
By keeping the older application installed and available to users, we can ensure that our new version can be successfully installed and enabled without any outage to our customers. When we are confident that the new version is enabled, we can make it available. New requests for the application will now be routed to the new version.
If we encounter any problems, we can simply make the new version unavailable, which reverts new requests back to the old version. When we are comfortable with the new version, and we are confident that all requests being processed by the old version of the application have completed, we can disable and discard it. We have successfully transitioned to a new application version across multiple CICS TS regions, with no application outage.
9.7 Outcomes
In this chapter, we described in detail the suggested system of semantic versioning, and how it can be used to record and track changes to GeneralInsuranceCustomer, in addition to communicating how those changes affect clients, data, and other applications running on the same platform. We introduced scenarios demonstrating the value of being able to run multiple versions of the same CICS TS application on the same CICS TS platform at the same time.
Then, we discussed how we could move version 1.200.0 of GeneralInsuranceCustomer, unchanged, from a single region development environment to a multi-region test environment using a different application binding. This binding allows for changes in the underlying platform, and differences in operational procedures between the environments. Finally, we showed how you can transition between different versions of an application, to either upgrade capability or back out a change, without causing an outage of the application.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.