Client Level and Spot Builds

(Revised 11/01/05)

Overview

The ROS build process has two main components, SERVER (UNIX platform) and CLIENT
(Windows platform). This document covers CLIENT builds. This document is intended for
people with basic understanding of Windows operation and a basic understanding of the build
requirements, although some UNIX commands are required for the CLIENT build.

Within the CLIENT build process, there are two build designations: LEVEL and SPOT. The
process for building LEVEL and SPOT builds is identical, except for naming convention and
audit reports.

LEVEL builds are scheduled in advance. The build schedule is available in document
“U:\Documentation – SNB Group\ROS\Teams\Configuration Management\Rel
Mgmt\release_schedule.doc”. U: drive is mapped to \\90.136.104.5\home2. LEVEL builds are
built at the same time as the SERVER level builds. The same notification for the SERVER
build from the Release Manager serves as notice to proceed with the client LEVEL build.

Details of servers designated for builds are available in document “Server Schedules.xls”
located "U:\Documentation - SNB Group\ROS\Project\Management\Release Planning”. U drive
is mapped to \\90.136.104.5\home2.

Server login on the CLIENT build server uses the Administrator account. Contact appropriate
person to obtain password.

Through out this documentation, reference is made to Harvest project and package groups.
For this document, the examples use Harvest project 2005.0D.Apr and package group 1.1.
The actual project and package number will vary depending on build. Substitute those values
for the examples shown.

BUILD DAY

The SERVER build procedure ‘AuditReport.ksh’ generates the Pre-Build audit report, adds
instructions to Team Leads and emails the report. Pre-Build audit reports are created for the
Client and Server at the same time. The UNIX script AuditReport.ksh is run by an ‘at’ command
on the primary build server. Refer to SERVER build process documentation. If the
AuditReport.ksh script did not get scheduled for run, or has failed to run, it will need to be run
manually on the primary build server. On the primary build server where the SERVER build is
being performed, login as ovrturcm and run the following UNIX command:
/ovrturcm/bin/AuditReport.ksh 2005.0D.Apr.Client 1.1

For client SPOT builds, no Pre Build Audit report is required. Therefore, do not run
AuditReport.ksh for SPOT builds.
The Release Manager will send notification that the build is ready to proceed. Do not start the
build until this notification has been received from the Release Manager.

Review the Harvest package names for spaces. If any are found, edit the package names and
replace the spaces with dash (-). Spaces can not be used in the package names. Spaces will
cause the Harvest extract to be incomplete and an unusable build will result.

For client LEVEL builds, all packages in the Integrate state will be processed. For client SPOT
builds, the Release Manager must designate the specific package(s) (defect or feature) that
are to be processed. These packages must be in the Integrate state.

In Harvest, create a package group appropriate for this build. The Release Manager should
confirm the package group number to be used. For LEVEL builds, it will be 1.1, 1.2, or 1.3. For
SPOT builds, it will be similar to 1.1.1, 1.2.1. 1.2.2 or some variation. See Harvest
documentation for procedure to create package groups.

Add the specific packages to the package group. If LEVEL build, all packages in Integrate
state. If SPOT, only the package(s) specified by the RM in Integrate state will be added to the
package group.

Promote the package(s) associated with the package group to the Build state. Confirm that all
packages needed for the build are in the Build state. For LEVEL build, there will be no
packages in the Integrate state. For SPOT build, visually check that defect or feature number
is in the Build state.

Client build process is performed on server 90.136.104.5, which is a Windows server. You will
need remote access software. Contact appropriate support group to have software
installed/configured. Login to 90.136.104.5 as “Administrator / C0mp4qR0x”.

Open Windows explorer window or My Computer to H:\Nant. The ROS Client build process
has been written using the Nant .Net scripting language. Edit the file PCGUI.Build.properties.
Change the values on the first section of lines to reflect the build requirements. Property
descriptions are: harvest.project is Harvest project name; harvest.package is Harvest package
group number; BuildType is either level or mid; PT_1 and PT_2 are the two Product Test
servers used for this release. If you are unsure of the values for PT_1 and PT_2, refer to
Server Schedule.xls file listed above. Do not edit any lines below the warning. Exit and save
changes.
Example of typical section of properties file. Values show in bold are edited.
<property name="harvest.project" value="2005.0E.May.Client" />
<property name="harvest.package" value="1.3" />
<property name="BuildType" value="level" />
<property name="PT_1" value="pt68" />
<property name="PT_2" value="pt70”

Run the Nant build process by double-clicking PCGUI_build.bat. Do not edit this batch file.
After approximately 3-5 minutes, the build will be complete. The command prompt window will
close. View file PCGUI_Prepare.out for errors. When the build is complete, it will be copied to
the level and PT download locations specified in the properties file.

Change directory to H:\IIS WEBS\PC GUI WEB\releases and confirm msi is in ‘Level’ directory
and in each PT directory specified in the properties table. Msi size should be approximately
1700-1800 KB.

A Post Build Audit report needs to be generated at this time. If using the UNIX system to
generate the SERVER LEVEL build, the bldit program will generate the Post Build Audit report
and email it.

For CLIENT LEVEL builds, notification to the Release Manager that the client build process is
complete should be incorporated in the notification page with the SERVER LEVEL build
process. (this is assuming the same person is doing both server and client builds) Notification
should state that client build is complete and placed in the product test (list product test server
numbers) download areas on the web site. For CLIENT SPOT builds, send notification to the
Release Manager that spot build number (list spot build number) is complete, builds have been
placed in product test (list PT numbers) download areas on web site and is ready for SAT.

SHIP DAY – SAT Complete

When RM has notified you that either Client LEVEL or SPOT build has completed SAT, client
will need to be copied to UAT download area, build notes will be updated, and Harvest work of
snapshot and promote to Production will be done.

Copy msi file from H:\IIS_WEBS\PC GUI WEB\releases\Level area and paste to UAT server
download area. RM will specify which UAT download area are used for this build. UAT
download areas exist under:
H:\IIS_WEBS\PC GUI WEB\releases
with specific directory names starting with UAT.

Build notes for the ROS client are generated as part of the UNIX server build process. No
addition input is required for build notes. Should errors occur, the build notes will need to be
created on the primary ROS build server for this build. Refer to document “Server Level
Builds.doc” for procedure to create build notes.

Harvest snapshot creation is incorporated into the ROS server build process. No additional
input is required. Should errors occur, refer to document “Server Level Builds.doc” for
procedure to create snapshot.

Harvest promotion of packages to Production state is incorporated into the ROS server build
process. No additional input is required. Should errors occur, refer to document “Server Level
Builds.doc” for procedure to promote packages.
Notify the Release Manager that Client build (list build name) has been placed in UAT
download area (list UAT servers), release notes have been updated and checked into Harvest,
snapshot complete and packages have been promoted to Production state.

Approximately two weeks after final ROS client is ready for production, it will be sent to EDS
for ITG/IOT review. Refer to document “Client msi packaging and deployment.doc”.