Build the application using Rational Build Forge

Build the application using Rational Build Forge In this lab, as the Build Engineer, you will run a formal build of Release 2.0 of the RatlBankWeb application. After the build completes, you will be able to view the results of the build and observe the build record created in ClearQuest. With a successful build in hand, you will create a deployment record in ClearQuest to request that the application be deployed to the SystemTest environment. Through completing this scenario, you will see how Rational Build Forge is integrated with Rational ClearQuest and Rational ClearCase to manage the build of applications and to capture important details about the build that supports your compliance/governance processes. You will further see how your build workflow can be automated by using these tools. For the purposes of this lab and all subsequent labs using the Build Forge Management Console, certain terminology will be utilized to reference areas of the user interface. Please reference the image below in regards to areas of the screen that will be referenced. 1 Modules Frame 2 Element Quick Selector Frame 3 Element Frame 4 Element Detail Frame Team role You are now performing the role of Jan, the Build Engineer. Login/Password: jan/jan 1. Log in to Build Forge. Page 62 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

The Build Engineer works in Build Forge s easy-to-use browser-based graphical user interface (GUI) to perform a build. a. Open Build Forge by double clicking the Build Forge Windows Desktop. shortcut on the b. Log in as Jan, the Build Engineer, using the following parameters, then click Login. - Username: jan - Password: jan Build Forge permissions As the Build Engineer, Jan has privileges above and beyond a developer-- such as adding, modifying, and deleting objects associated with or in support of a build project (for example, users, projects, environment variables). A developer typically has sufficient privileges to execute a all or a subset of a build project. 2. Examine the project environment and build steps. a. Click the Environments module, then click RatlBankWeb INT. This shows all of the environment variables that have been defined for building the RatlBankWeb project. These can be a combination of external (operating system) environment variables and internal (Build Forge) environment variables. Environments The Build Forge system allows you to manage groups of environment variables separate from the projects and servers that they apply to. This paradigm provides you with a great deal of flexibility in creating the environment for any particular command: You can create environment groups which contain environment variables. You can nest environment groups together. You can assign one environment group to each server, one to each project, and one to each step within a project. When the system runs a step, it applies all the relevant groups to create the step environment: server, project, and step groups, in that order. Lab 3 Page 63

b. Click the Projects module and then RatlBankWeb Int to show the steps that have been defined for building the RatlBankWeb project. Click some of the steps to further explore the project. Command Line Integration These steps are an example of command line integration. The Build Forge agent can execute command lines directly on a system with a Build Forge Agent installed. This makes Build Forge easy to integrate with any application or tool that has a command line interface. Command Line Integration allows development organizations to use their current tools and scripts to minimize migration efforts and maximize their return on investment. Furthermore, it enables Build Forge to work with the Page 64 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

new tools your teams will want to introduce in the future; when a department decides to change its tools, you can plug the new tool into the Build Forge system with ease. Moreover, you can sidestep tool arguments with the Build Forge system: each team can use the tools that it has found successful. IBM More on Build Forge permissions Note that some of these steps are accessible by Developers and some (usually ClearCase baselining/staging operations) are only accessible by the Build Engineer. Also note that a number of these steps have been specified to run in parallel (threaded). 3. Run the RatlBankWeb_Int build project. a. You will run the build directly from inside the Build Forge Management Console. Click Start Project. The specific values of the environment variables for this execution are displayed on the Job Details tab and the steps to be run will be displayed on the Job Steps tab. With sufficient privileges, you can override any of these now. b. Optionally configure job run to automatically create a deployment record. The Build Engineer is building the application so it may be deployed to the initial test environment for validation. After the application has been successfully built and a deployment baseline created, a deployment record must be created (per Rational Bank s process) to request and track the deployment. This can be done automatically as part of the RatlBankWeb Int build project or manually by the Build Engineer later in this lab. If you would like to have Build Forge do this automatically, while on the Job Details tab, set the AUTO_CREATE_DTDEPLOY environment variable to Yes. c. The CQ_DEPLOY_TYPE is used only if AUTO_CREATE_DTDEPLOY is set to Yes. It is used to set the Deploy Type field on the ClearQuest deployment record. By default, the RatlBankWeb Int project is configured to initiate deployments via ClearQuest and accomplish them using TPM (Lab 4a). Lab 3 Page 65

Deployment Options In Lab 4a, the deployment is initiated by ClearQuest and accomplished by TPM. In Lab 4b, the deployment is initiated by Build Forge and accomplished by either Build Forge or TPM. If you are not sure which deployment option is being used during this PoT, make sure you confirm with your instructor. If you will be initiating the deployment via Build Forge (Lab 4b), regardless of whether it is accomplished by TPM or Build Forge, set CQ_DEPLOY_TYPE to BuildForge. d. Click Execute. The build will start and show the execution progress of the project run. You can click any Step Name to drill down into any of the steps to display more detail about what Build Forge is doing. This will bring up a new page showing the log for that step. Page 66 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

To return to the project execution page, click the browser back button or build tag (NN_INT) link at the top of the page. e. While the project runs, wait until the project run Status shows Completed before moving on to the next step. 4. Note the deployment baseline. The build project created a deployment baseline to be used when deploying the revised application. This baseline is needed in the deployment lab. a. After the build has completed in the previous step, click the Create Deployment Baseline step of the project run. b. Scroll down to the end of the Step Log. c. Make note of the label for the baseline created for the RATLBANKWEB_REL component. This baseline label will be needed if performing Lab 4b ( Deploy the application using Build Forge ). Using one of the Build Forge dot commands (.set), the baseline label is saved for use later by Build Forge in the RatlBankWeb Dep project. Lab 3 Page 67

5. If you set AUTO_CREATE_DEPLOY environment variable to Yes, then note the id of the auto created deployment record. a. Click the Create Deployment Record step of the project run. b. Scroll down to about the middle of the Step Log. c. Make note of the record id for the deployment record. This id will be needed if performing Lab 4b ( Deploy the application using Build Forge ). Using one of the Build Forge dot commands (.set), the id is saved for use later by Build Forge in the RatlBankWeb Dep project. 6. Examine the bill of materials. Build Forge generates a bill of materials (BOM) after each project run. The BOM contains information about the steps in the run and the changes to files that resulted from it. The BOM can be provided to consumers of the project run, such as the quality assurance department, for help in understanding the contents of a new build. It can also serve as an audit solution for your build and release process. Page 68 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

a. Click Bill of Materials to display the bill of materials. The bill of materials displays the steps that were executed as well as the ClearCase source changes that were included in the build and the ClearQuest defects that were resolved. b. Expand Job Steps to display the steps executed and their status. c. Expand Source Changes to display the version(s) of ClearCase sourcecontrolled elements that were included in the build. Note also that the BOM Lab 3 Page 69

includes the differences between the version used in the build and its previous version. d. This BOM also contains information on the ClearQuest defect(s) tested by this build. Expand ClearQuest Defect Information. Observe the ClearQuest adaptor used by this project has automatically resolved the defect record and associated it with the ClearQuest build record used to track the results and status of this build. Note depending on the state of the VMware image, the actual record IDs may vary from the picture above. e. Click the Logout link in the upper right of the Build Forge Management Console then close the Firefox browser. 7. Examine your e-mails. a. Build Forge can also send e-mails notifying you of build success or failure. To examine these e-mails, start up the Thunderbird e-mail reader by double-clicking the Mozilla Thunderbird shortcut on the Windows Desktop. b. Click the jan@ratlbank.com folder. c. Observe the e-mail received notifying Jan of the build completion status. d. Close Thunderbird. Page 70 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

8. Examine the defect. With the Build Forge integration with ClearQuest, defect records can be populated with build results and automatically transitioned to an appropriate state in your change management workflow. a. Open ClearQuest by double-clicking the ClearQuest shortcut Windows Desktop. on the b. Select File Database Connect jan,7.0.0@rbu to log in as the Build Engineer, Jan. Entering Jan s password This lab was pre-configured to remember Jan s password. However, if prompted for a password enter: jan Select the option to Remember the password. c. Find the defect you created earlier by double-clicking the query Public Queries All Defects. d. Scroll to the bottom of the list to find the defect submitted in the previous lab. Double-click the defect record. e. In the View Defect window, notice that this record has been resolved automatically for us by Build Forge (that is, its current state is now Resolved). Click the Notes tab to display the build it was resolved in. Lab 3 Page 71

Actual record IDs Depending on the state of the VMware image, the actual record IDs generated may vary (for example,rbu00000259 in the previous screen capture). Keep that in mind as you compare your actual display to the screen captures included in this lab workbook. f. Click the Unified Change Management tab. This displays information about where in ClearCase the work on this defect took place. Click View Change Set. Page 72 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

Unified Change Management (UCM) Applying a ClearCase- and ClearQuest-enabled Unified Change Management process allows all changes to all files/directories to be tracked when working on a particular change request (for example, a defect). This change set is tracked by the ClearCase/ClearQuest integration and available for review from the UCM tab of a ClearQuest record. g. In the Properties window for the ClearCase activity (that is, the defect you are viewing), note that the listtransactions.jsp file is listed as being changed as a result of working this defect. Right-click the listtransactions.jsp file and select Version Tree. Notice also the other options (such as History and Compare with Lab 3 Page 73

previous version) to perform IBM Rational ClearCase operations on the file. h. Examine the version tree for listtransactions.jsp. Note that on your version of the file, both the activity and the new baseline(s) automatically created by Build Forge have been recorded. Page 74 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

9. i. Close the Version Tree window. j. Click Cancel to close the change set display. Click Cancel to close the defect window. Display the build record. You can also display the details of the Build Record that was automatically created in ClearQuest by Build Forge. Lab 3 Page 75

a. To navigate to the build record, double-click the Public Queries All Builds query. b. Double-click the record for the build record associated with your build (48_INT). The build record will be displayed. Page 76 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

c. Click the Build Details tab for the build record associated with your build (NN_INT). Here you will see the BuildLog showing the steps executed and their pass/fail results and a Build Web URL hyperlink to the project run in Build Forge. Lab 3 Page 77

d. Click the hyperlink Build Web URL field to view the project run in the Build Forge Web GUI. e. Log in as Jan, the Build Engineer, using the following parameters, then click Login. - Username: jan - Password: jan Page 78 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

f. Observe that the project run associated with this build record is displayed. g. Click the Resolution tab and observe the defect(s) associated with this project run and the source baseline used to build the application. These are not part of the standard ClearQuest/Build Forge integration but may be easily extended to do so. Lab 3 Page 79

h. Click the Logout link in the upper right of the Build Forge Management Console, then close the Firefox browser. Page 80 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

i. Click Cancel to close the build record window. 10. Create a deployment record If you chose to have Build Forge automatically create the deployment record when running the RatlBankWeb Int project, proceed to the next step. Rational ClearQuest supports a deployment approval process by creating records of type DTDeployment. You associate each deployment record you create in Rational ClearQuest with a release record. You then use Rational ClearQuest to transition the deployment record through the ordered testing environments in your release s deployment process, obtaining approval from the appropriate role(s) before the deployment record can move from its current environment into the next environment in the series. When creating a DTDeployment record, you associate a deployment unit based on the results of your most recent build. The deployment unit lists the artifacts to be deployed. a. Back in IBM Rational ClearQuest, select File New DTDeployment. b. For Headline, type Deploy RatlBankWeb v2 Build. Enter RatlBank_2.0 for Release. Lab 3 Page 81

c. Click Browse next to the Deployment_Unit_Reference field. Navigate to C:\Builds\RatlBankWeb_49_INT\RatlBankReleases\web and select du_decorated_49_int.xml. Click Open. Note: If your build tag was different, you will need to browse to the folder with that build tag in the name and select the corresponding XML file (du_decorated_nn_int.xml). About deployment units A deployment unit defines the list of artifacts to be deployed to an environment. Deployment units are both created and managed using the Rational ClearCase command-line utility called the XML Decorator, or du_tool.pl. d. Enter dana as the Owner. e. There are two deployment lab options. Lab 4a is for deploying through Tivoli Provisioning Manager. Lab 4b is for deploying through the Build Forge Management Console. Based on which path you are taking in this workshop, select Build Forge or TPM for the Deploy Type field. Using a Deploy Type field allows you to customize the workflow used for this PoT based on the deployment technology to be used. Page 82 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

f. Your deployment record should look something like the one in the following screen capture. Make note of the record ID (that is,rbu00000262). This will be needed if performing Lab 4b. Click OK. Lab 3 Page 83

Actual record IDs Depending on the state of the VMware image, the actual record IDs generated may vary (for example,rbu00000262 in the previous screen capture). Keep that in mind as you compare your actual display to the screen captures included in this lab workbook. 11. Review the deployment record a. In the left tree view, double-click Public Queries DeploymentQueries DeploymentsForRelease to run the query. b. Select the RatlBank_2.0 release name as a filter. Click OK. c. In the Result Set view, select the deployment record that you created in the previous step (or was automatically created by Build Forge). The deployment record details display. d. Confirm the deployment record is correct. 12. Associate the build record with the deployment record. a. Double-click the deployment record Page 84 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

b. Click Modify. Modifying an existing ClearQuest record To modify the release record, use the highlighted icon in the toolbar. c. Click the Build tab in the displayed record form. d. Click Add. Lab 3 Page 85

e. In the Browse Record Type window, click Browse. This will display a tree view of all personal and public queries available. Select Public Queries All Builds and click OK. f. The first Build record in the list should be for your recent build. Select that record and click OK. Page 86 Discovering Build and Deployment Automation with IBM Rational and Tivoli Solutions

g. Click OK to save the record modifications. h. Close ClearQuest. Lab 3 Page 87