Build environment
This chapter describes the tools and process to automate reliably and repeatably the building of CICS Transaction Server V5.3 applications and bundles. This chapter describes these items from the perspective of a build engineer, with a focus on build automation and continuous integration.
This chapter covers the following topics:
3.1 Automated build
The agile approach brings dramatic changes in the software development process. Software development is now done in smaller pieces as a way to deliver new functions faster. There is a new continuous integration approach in which developers deliver code in chunks and software updates are released more frequently.
Automated build is a key part of continuous integration. A build is a process in which software artifacts, including source code and resources, are compiled, packaged, and made ready for deployment. Automated build is a repeatable build process that can be performed at any time that requires no human intervention. The build utility tools that are described later in this chapter make implementing automated builds easy.
A typical automated build scenario is shown in Figure 3-1 and described in the paragraphs that follow it. This chapter focuses on the build automation part of the diagram.
Figure 3-1 DevOps build automation
As shown in Figure 3-1, a development and operations (DevOps) build scenario follows these steps:
1. Developers check in their code to a source code management (SCM) system
2. A Build Engineer uses various tools and scripts to create a build automation process. The output of the build automation process is a set of deployable artifacts that are stored in the build repository
3. The Build Engineer also creates the post-deployment process that publishes the artifacts to the deployment repository.
3.2 Automated build in CICS Transaction Server
This section describes the tools and process that are required for build automation and how an automated build process is created.
The tools that are used for this book are listed in Table 3-1 on page 21. Different tools can be used, but we choose these products because there is good integration between them. Better integration between tools leads to better DevOps processes.
Table 3-1 Functions and tools for automated builds
|
Function
|
Tool
|
|
Continuous build
|
Rational Team Concert)
|
|
Build engine
|
Rational Team Concert
|
|
Build utility
|
IBM CICS Transaction Server build toolkit (CICS build toolkit), IBM UrbanCode Deploy z/OS Deploy Toolkit
|
|
Build repository
|
IBM UrbanCode Deploy CodeStation
|
Figure 3-2 shows the tools that we describe in this chapter for build automation.
Figure 3-2 Build environment
3.2.1 Build objects in Rational Team Concert
The following types of basic build objects are used for configuring and running Rational Team Concert builds:
•Build engine
•Build definition
•Build request
•Build result
We describe the build objects in detail in the following section.
Build objects
The build component of Rational Team Concert supports the automation, monitoring, and build awareness of team builds. The team build component integrates the team's build system into Rational Team Concert, providing build awareness, control, and traceability to the team. Team members can track build progress, view build alerts and results, request builds, and trace builds to other artifacts, such as change sets and work items. Team members can see what builds there are, inspect build results, monitor builds in progress, and request builds at any time, all within the Rational Team Concert Eclipse-based IDE. Rational Team Concert Build provides a model for representing a team's build definitions, build engines, and build results. Figure 3-3 introduces the build objects that abstract, organize, and store build settings. We describe the build objects in Rational Team Concert in detail.
Figure 3-3 Build objects
These basic build objects are used for configuring and running builds by using Rational Team Concert Build:
•Build engine
A build engine processes schedule and manual build requests, starts and completes builds, and publishes build logs. Build engines provide a standard way to support and interact with various build technologies. In Rational Team Concert, a build engine is an abstraction of the build technology and is how Rational Team Concert interacts with the build technology in an operational sense. The build engine runs external to the target system. It can even run on other systems, which allows load to be shared and also provides isolation for different types of builds.
•Build definition
A build definition specifies a collection of settings and properties for a build, such as the events that must occur before the build, what is to be built and where, what happens after the build, and how the build logs its tasks.
A build definition is based on a build template, which provides base settings and capabilities to create builds for your platform, compiler, and environment. The template that is most often used for CICS/COBOL applications is Rational Build Agent - Dependency Build. The Ant IBM Jazz™ Build Engine template is used to build non-COBOL applications, such as CICS bundles.
A build definition uses a repository workspace. It fetches the artifacts from the repository to build it. This must be a dedicated repository workspace, which is owned by a designated build user.
You can configure pre- and post-build settings to specify what files to fetch from the repository workspace, and where they should be built. There are also optional settings, including automatic scheduling, email notification, and pre- and post-build command options.
•Build request
A build request instructs the build server to run a build. Build requests can happen automatically (when triggered by schedules or by changes being delivered) or manually by human intervention.
•Build result
The build result contains the output from a build, such as execution summaries, logs, and properties. A build result is available when the build request begins processing. When you open a build result in progress, you can view build progress from the Activities tab of the build result editor. You can also refresh a build result that is in progress.
3.2.2 Using Rational Team Concert Enterprise Extension to build CICS COBOL applications
Rational Team Concert includes support for IBM z Systems and other enterprise-level platforms. This function is unlocked through the Developer for IBM Enterprise Platforms Client Access License and includes the z/OS Dependency Build template. The z/OS Dependency Build is used to compile and link-edit COBOL and PL/I applications.
Figure 3-4 shows how the user selects the z/OS Dependency Build during the build definition process.
Figure 3-4 Select the z/OS Dependency Build during the build definition process
The build process for COBOL applications is shown in Figure 3-5 and described in the paragraphs that follow it.
Figure 3-5 Build process for COBOL applications
Here are the steps in the COBOL application build process that is shown in Figure 3-5 on page 24, particularly regarding the Rational Team Concert server and repository:
1. The developer delivers project artifacts to a stream and then schedules an automatic build request based on the build definition. A stream is a collection of one or more components. A component is a collection of related artifacts, such as the code for a plug-in, or the group of documents that are used on a website. Artifacts under source control are grouped into components, which can be included in zero or more streams. Any group of files and folders that share a common root can be a component. Streams allow an organization to work on different versions of the same components in parallel. For example, one stream can be configured for the most recent version of a release’s components, and another stream can be configured for the maintenance of an earlier version of that same software.
2. The Rational Build Agent build engine runs on the build machine, producing the appropriate build files and output. The build files are generated based on the build definition and z/OS system definitions (data set definitions, language definitions, and translators) in the Enterprise Extensions folder of the project area.
When you begin a build, the build process accepts all of the latest changes from the stream into a build-owned repository workspace and creates a snapshot of the files. The change sets and work items that are included in the build are linked to the build.
You can create build definitions to call existing host build facilities or JCL. The z/OS build agent is integrated with the Job Monitor capability to provide proper job submission and monitoring.
The Ant with Enterprise Extensions build capability is based on Apache Ant extensions to build any z/OS artifacts. The Rational Build Agent engine relies on the following artifacts:
Data set definitions
Data set definitions are containers of information about a data set or library on a remote z/OS system. All data sets that are referenced by a build process must have a corresponding data set definition. Among the data set definitions that you must create are the COBOL listing output and CICS load modules.
In this example, we create a data set definition that is named CICS STAGING LOADLIB for the staging load library that we use with IBM UrbanCode Deploy. This data set is not allocated because it is already created on our z/OS system. To create the data set definition, complete the following steps:
1. In the Team Artifacts view of Rational Team Concert, expand your project area and then click Enterprise Extensions folder → System Definitions → z/OS. Right-click the Data Set Definitions node and click New Data Set Definition.
2. Give the definition a name, in this case, CICS STAGING LOADLIB.
3. Give the data set a name, in this case, CICSDPP.SCEN1.LOAD.
Figure 3-6 shows the Data Set Definition window.
Figure 3-6 Data Set Definition window
Language definitions
Language definitions establish how to build a program. Each z/OS program that you build with Rational Team Concert has an associated language definition that contains multiple steps, represented by translations that are performed on a file during a build. Translators defines the steps that are required to build program for a specific language. One or more translators are associated with language definitions. A language definition specifies the steps, or translators, that must be performed during the build. Each program that is built in z/OS must be associated with a language definition. The tasks are defined by using a translator, such as the IBM DB2 preprocessor, CICS translator, or COBOL compile.
Figure 3-7 shows the Language Definition window with appropriate selections to create a language definition.
Figure 3-7 Language Definition window
Translators
As part of a language definition, translators describe the operations that are performed on a program during a build. Language definitions that contain no translators are used for simpler operations, such as collecting source code data.
A translator is similar to a JCL job step and specifies the compiler or translator to be used, the data set definition allocations that are needed by the compiler, and the maximum return codes. Depending on the COBOL compiler version that you use, the steps can also include DB2 precompile, CICS precompile, COBOL compile, link-edit, or DB2 bind.
Figure 3-8 shows a translator for the COBOL program.
Figure 3-8 Translator for the COBOL program
Creating build definitions for z/OS
Rational Team Concert helps you define builds and manage them. Rational Team Concert Build provides a template for representing the definitions, engines, and results for team builds, including support for different build technologies. The following build definition templates are available for z/OS:
•The Ant with Enterprise Extensions build template is a build definition for z/OS that uses the Rational Build Agent build engine and a version of the Ant build toolkit that is extended to work on z/OS. The Ant build toolkit is suited for Ant builds, but you can use any scripting technology that can start Ant.
•The z/OS Dependency Build template is used to build only those items that changed or depend on changes since the last successful team build.
Figure 3-9 shows the z/OS Dependency Build tab within Rational Team Concert.
Figure 3-9 z/OS Dependency Build tab
3.2.3 Using Rational Team Concert to build CICS cloud applications and bundles
Section 3.2.2, “Using Rational Team Concert Enterprise Extension to build CICS COBOL applications” on page 23 described the process of building a CICS/COBOL application by using Rational Team Concert Enterprise Extension. This section describes how to build a CICS bundle or CICS cloud application. You create the build definition by using the Ant – Jazz Build Engine as the template, as shown in Figure 3-10 on page 29, although a number of different build templates are available for this purpose, including some that work from the command line.
Figure 3-10 New Build Definition window showing the selection of the Ant – Jazz Build Engine
The following tabs are used to establish the key components of build definitions for CICS cloud applications and bundles:
•Properties tab
•Jazz Source Control tab
•Ant tab
In this example, we show how to create a definition for a CICS bundle by completing the following steps:
1. In the Properties tab (see Figure 3-11), specify the source directory of the bundle definition, the name of the bundle definition, and the output directory of the build. The specific entries that you make on this tab depend on the particular bundle you are creating.
Figure 3-11 Properties tab with selections for a CICS bundle
2. In the Jazz Source Control tab (see Figure 3-12), create a repository workspace for the build. Specify the load options for the build, including the source directory and the components to exclude from the build. Your entries are specific to the bundle you are creating.
Figure 3-12 Jazz Source Control tab with selections for a CICS bundle
3. In the Ant tab (see Figure 3-13), specify the build script that runs the Ant tasks that communicate with the Jazz Team Server. The script fetches source files to compile from a stream or workspace, reports progress, and creates the build output. In the example that is shown in Figure 3-13, we designate the build.xml Ant script that runs the CICS build toolkit to create CICS bundles.
Figure 3-13 Ant Tab with selections for a CICS bundle
The Ant script build.xml that runs the CICS build toolkit is shown in Example 3-1. We provide details about the CICS build toolkit command in 3.3.4, “CICS build toolkit” on page 36.
Example 3-1 Build.xml Ant script that runs CICS build toolkit
<exec executable="${cicsbt.install.dir}/${cicsbt.command}"
failonerror="false" resultproperty="return.code" dir="${user.dir}">
<env key="IBM_JAVA_OPTIONS" value="-Xshareclasses:name=cicsbt,groupAccess" />
<arg line="--input ${source.dir}/*
--build ${bundle.name}
--target ${target.platform}
--workspace ${cicsbt_workspace}
--verbose" />
</exec>
3.2.4 Using Rational Team Concert for continuous builds
One of the keys to the DevOps approach is the ability to do continuous builds without any human intervention. The continuous build concept means that developers need only to check in their code to an SCM system for a build to be triggered. Builds are triggered only if the system determines that the checked-in code contains changes from what was previously in place.
Rational Team Concert supports the continuous build process while creating the build definition. The build schedule can be configured to run at a specific interval, such as every
5 minutes.
5 minutes.
So, to achieve continuous build, you start by setting the build definition schedule in the Schedule tab (see Figure 3-14). Within the tab, make these selections:
•Select Enabled to enable automatic builds.
•In the Continuous interval in minutes field, type your preferred interval (for example,
5 minutes).
5 minutes).
•In the Build days pane, confirm that you identified the days when you want builds to run.
Figure 3-14 Enable and set the build definition schedule
To establish that builds be performed only if new changes are delivered to the stream, select the Build only if there are changes accepted option on the Jazz Source Control tab, as shown in Figure 3-15.
Figure 3-15 Jazz Source Control tab with a setting to perform builds only when changes are accepted
3.3 Build automation utilities
The build engine runs one or more build automation utilities, where the bulk of build activity is completed. These utilities take the source items and perform operations on them, such as compiling, link-editing, and packaging.
Particular build automation utilities often work best with particular application types or styles. For example, the make utility is often associated with C and C++ builds, Ant and Maven are typically used for Java builds, and JCL is the preferred utility for z/OS compatible languages, such as COBOL and PL/I.
When building CICS applications, you can use many different build automation utilities, depending on the application being deployed.
3.3.1 Utilities for traditional CICS applications
When a CICS application is composed primarily of COBOL load modules, use JCL to run compile and link-edit jobs. Optionally, you can use more advanced structures such as Rational Team Concert Enterprise Extension build definitions and CA Endeavor generate processors, as shown in Figure 3-16 on page 35.
Figure 3-16 The process of building traditional CICS applications
3.3.2 Utilities for CICS bundles and cloud applications
When a CICS application is composed of CICS bundles or cloud applications, use the CICS build toolkit to build the artifacts into their installable form.
You can run the CICS build toolkit from a shell or batch script running on Windows, Linux, or z/OS by using the BPXBATCH program from JCL. You can use other tools too. For example, if you use Ant, you can run the CICS build toolkit with the <exec> task. The process of using the CICS build toolkit to build CICS bundles is shown in Figure 3-17.
Figure 3-17 The process of building CICS bundles and CICS cloud applications
3.3.3 Utilities for CICS Java applications
When a CICS application is composed of CICS bundles or CICS cloud applications that also include Java code, you can build the Java code by using the CICS build toolkit’s Java build feature. This process is shown in Figure 3-18.
Figure 3-18 Process to build CICS Java applications by using the CICS build toolkit’s built-in Java build
Alternatively, you can build the Java build separately by using other Java build methods, such as Ant, Maven, or Gradle, before you use the CICS build toolkit to finish the process. To do this task, run the external Java build as required and copy the necessary JAR, WAR, EAR, or EBA files into the relevant directory in the CICS bundle. This process is shown in Figure 3-19. WAR, EAR, and EBA files must be named in this manner:
symbolicname_version.extension
For example, name the file org.example.website_1.2.3.war.
Figure 3-19 Process of building CICS Java applications, by using external Java build methods
3.3.4 CICS build toolkit
The CICS build toolkit provides a command-line interface (CLI) for automating builds of CICS projects, including bundles, applications, and application bindings. CICS build toolkit also supports projects that are referenced by CICS bundles, including OSGi applications, OSGi bundles, enterprise applications, and dynamic web projects, and can take pre-built OSGi bundles and Liberty applications as input.
Build automation
In a continuous integration environment, a build script runs automatically when a developer checks in an updated version of an application. The build script calls CICS build toolkit to build the projects that form the application. The script checks the result of the build for errors and, if appropriate, copies the built projects to a suitable location, such as an artifact repository (UrbanCode CodeStation, for example) or a staging area on zFS.
Resolving build variables
To facilitate the deployment of the same application to different environments, such as development test and production, you can replace hardcoded values in bundle part attributes with variables. A deployment script can then use the CICS build toolkit to resolve the variables with specific values, which are defined in a properties file, that are appropriate for the target environment. This process is described in Chapter 4, “Release environment” on page 43.
Installing the CICS build toolkit
The CICS build toolkit is supported on the z/OS, Linux, and Microsoft Windows operating systems and comes with CICS Transaction Server in the form of a downloadable cicsbt_v#######.zip file.
Software requirements
The CICS build toolkit requires a Java 7 compatible Java Runtime Environment (JRE) or Java Development Kit (JDK), either 32-bit (31-bit on z/OS) or 64-bit.
Installing the CICS build toolkit
Regardless of the underlying platform, to install CICS build toolkit, complete the following steps:
1. Download the most recent version of the cicsbt_v#######.zip file from the following website:
2. Transfer the cicsbt_v#######.zip file in binary format to the system on which you run the CICS build toolkit.
3. Extract the cicsbt_v#######.zip file to create the cicsbt directory. For example, on z/OS, run the following command:
jar -xf cicsbt_v#######.zip
Building a CICS bundle, application, or application binding
Automated builds of CICS projects, including CICS bundles, applications, and application bindings, can be done with build scripts that call the CICS build toolkit. The process of creating the build automation is done after development and before deployment.
You start the CICS build toolkit from the CLI. Here are the commands for each platform:
•Linux: cicsbt
•Windows: cicsbt.bat
•z//OS: cicsbt_zos
Example 3-2 shows a sample CICS build toolkit command in Linux. It builds the latest version of the bundle by using a symbolic name and version number from an input directory indicating the location of the CICS projects and any referenced projects to be built, and uses the CICS Transaction Server V5.3 target to build the referenced Java project. The source and output files must be on the local file system where the CICS build toolkit runs.
Example 3-2 Sample CICS build toolkit command
cicsbt --input /top/leve/source/dir/*
--build my.cics.bundle(1.0.0)
--target com.ibm.cics.explorer.sdk.runtime53.target
--output /output/dir
--workspace /cicsbt_workspace
--verbose
Example 3-2 includes several parameters for running the CICS build toolkit:
•Input parameters
The input parameters (specified by –input) indicate the location of the CICS projects to be built and any referenced projects. The asterisk at the end of a path tells the CICS build toolkit to build all projects in that directory in a single call.
•Build parameters
The build parameters (specified by --build) indicate which CICS bundles, applications, and application bindings to build from the source location.
A project can be specified with either the symbolic name and version (for example, my.cics.bundle(1.0.0)), or path to the project (for example, /u/maitra/applications/myApplication). If you specify a symbolic name but do not specify a version, the CICS build toolkit builds the highest version of the project that is available. Therefore, use symbolic names.
•Output parameter
The output parameter (specified by --output) indicates the location of the output directory. The CICS build toolkit creates subdirectories for applications and bundles by using names based on their symbolic name and version. If only applications or bundles are built, they are placed in the /applications and /bundles subdirectories. If one or more application bindings are built, then all associated artifacts are placed in a directory structure that includes the platform name. Any applications or bundles not associated with a binding are placed in subdirectories, as is usually the case.
•Target parameters (optional)
The target parameters (specified by --target) indicate the target platform that is used. The target platform defines the Java libraries (APIs) that are required to build referenced OSGi bundles and OSGi applications. The target platform can be predefined, such as a CICS release, or it can be an Eclipse .target file that is created by the user.
•Encoding parameter
The encoding parameter (specified by –-encoding) indicate the Internet Assigned Numbers Authority (IANA) character set name that represents the default CCSID for the CICS region into which the bundle is installed. This parameter is optional. If it is ignored, the default of cp037 is used.
•Workspace parameter
The workspace parameter (specified by --workspace along with a path name) provides the path of the Eclipse workspace that the CICS build toolkit uses. If this parameter is not included in the CICS build toolkit command, a temporary Eclipse workspace is created and then deleted after the command completes. It is important to specify a unique workspace directory if you are running multiple builds concurrently.
•Verbose parameter
The verbose parameter (specified by --verbose) is ideal for debugging, as it provides extra details to the console about the progress of the CICS build toolkit run.
3.4 Publishing artifacts to IBM UrbanCode Deploy
After the application is built and packaged, it must be available in the deployment repository before the automated deployment process can proceed. In our example, the deployment repository is the IBM UrbanCode Deploy CodeStation, so a new component version must be created.
Based on the type of build to be performed, different processes are used to create the component versions. This section shows the steps for creating a z/OS component version and a CICS bundle component version.
3.4.1 Creating a z/OS component version
In IBM UrbanCode Deploy, deployable items are combined into logical groupings called components. Components have versions. Component versions in UrbanCode CodeStation are created after the build is done.
The IBM UrbanCode Deploy z/OS Deploy Toolkit includes utilities that help deploy the build artifacts to component versions. The utility that we use in our example is called Buztool. Buztool is a UNIX shell script that can be run from JCL, TSO, or z/OS UNIX System Services.
Buztool needs the load libraries, database resource management (DBRM), if any, and ship list file as input. It creates the component version, as shown in Figure 3-20.
Figure 3-20 Buztool flow for creating the component version
Example 3-3 provides an example of the JCL that runs Buztool to create a component version in IBM UrbanCode Deploy CodeStation.
Example 3-3 Sample JCL to start Buztool
//*
//ST1 EXEC PGM=IKJEFT01,DYNAMNBR=30,PARM='%ISPFCL',REGION=0M
//SYSEXEC DD DSN=REDS01.UCDTLKT.SBUZEXEC,DISP=SHR
// DD DSN=SYS1.SISPCLIB,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//PROFILE DD DSN=REDS01.UCDTLKT.SBUZSAMP(MYPROF),DISP=SHR
//ISPPROF DD RECFM=FB,LRECL=80,SPACE=(TRK,(2,2,2))
//ISPLLIB DD DSN=SYS1.SISPLOAD,DISP=SHR
//ISPMLIB DD DSN=SYS1.SISPMENU,DISP=SHR
//ISPTLIB DD DSN=SYS1.SISPTENU,DISP=SHR
//ISPPLIB DD DSN=SYS1.SISPPENU,DISP=SHR
//ISPSLIB DD DSN=SYS1.SISPSLIB,DISP=SHR
//SYSTSIN DD *
ISPSTART CMD(BUZTOOL "createzosversion" -
"-c" "GENAPP Base" -
"-v" "version2" -
"-s" "/var/cicsts/devops/scenario1/build/shiplist.xml")
/*
3.4.2 Creating a CICS bundle component version
After the CICS bundle is created, you must set some options on the Post-Build Deploy tab of the build definition (see Figure 3-21).
Figure 3-21 Post Build Deploy options
The Build Definition has a post-build section that you can specify what to set after the build is completed. You can automatically set up deployment to IBM UrbanCode Deploy CodeStation by specifying options in the trigger policy. On this tab, you establish the trigger policy for when to deploy the built artifacts and the IBM UrbanCode Deploy server information. Here is what we established for this example:
•Enabled the post-build deployment
•Set it to deploy only if the build has no errors or warnings
You also must provide the IBM UrbanCode Deploy server information that shown in Figure 3-21.
You must provide the component name and version, and the files that are to be included in the component version. As shown in Figure 3-22, in this example, we use the existing component. We use the version name to be built dynamically with the build label. The build label is a built-in property of the build engine. The build label is a unique label generated by the build engine, for example, 20151107-1234.
Figure 3-22 Publish new component version
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.