1.

Introduction to RTC:
DARP (Development Architecture Redesign Project) has been developing IDEAZZ
(Integrated DEV Environment for Application Development on the Jazz platform)
for Telstra CC&B.

IDEAZZ enables lifecycle management, source control, and automated packaging

& deployment of code.

The IDEAZZ solution currently uses RTC (Rational Team Concert) and RBF (Rational
Build Forge), along with custom built scripts to enable automated build, packaging
and deployment of code, with end-to-end traceability.

2. RTC Thick Client Installation Steps:

- Connect through VPN.
- Click on the shared folder link - \\nus725pj.in.telstra.com.au\olbdata\08 -
OLB Training Doco\Training RTC
- Copy ‘RTC-Client-Win-4.0’ from the shared folder link into your local
machine and extract the file into your local folder.
- Go to ‘jazz\client\eclipse’ folder from the extracted file.
- Click on ‘eclipse.exe’ to launch RTC

- Provide the ‘workspace’ folder name

- After providing the ‘workspace’ folder name, click Ok.
- RTC Thick client will open up as below
- Close the ‘Welcome’ tab
- Click on ‘ Create a Repository Connection’

- Provide the details as shown below

- URI: https://ideazz-rtc.in.telstra.com.au:9443/ccm
- Name: ideazz-rtc.in.telstra.com.au
- Authentication Type: Username and Password
- User ID: enter your RTC ‘user name’ (d-number)
- Password: enter your RTC ‘password’
- Click ‘Finish’
- The repository connection names displayed under the ‘Repository
Connections’ as shown below.

- Right click on the connection name under “Repository Connections’ as

shown below.
- Click on the ‘Manage Connected Project Areas’ from the options.

- Select the check box of the below projects and Click on Finish.
 PA_DEVOPS
 PA_TDP_CCB
- You have successfully installed RTC thick client on your machine now.
3. RTC Check in Process:
- Right click on ‘My Repository Workspaces’ to create your repository
workspace as below.
- Click on Next and provide the Repository Workspace Name with the below
naming convention. (recommended)
WS_<<d-number>>_<<ERXXXX>>_EAI_TDP_DEV
- Follow the below screenshot to finish the process.
- Repository workspace is created successfully.
- Click on the repository workspace and ensure the Flow target is set to the
right stream.

- Follow the below screenshots, to load the required events from the stream.
- We can also select the root VOB (eg: CBT_TIBCO_BILLINVOICE) to get all
components within that VOB.
- You must select the first option if you want to load the entire VOB structure
(which loads the root folder as well).
- Now all the required components are loaded in your local workspace to
start your build.
- Work Items has to be created for any delivery through RTC.
- RTC supports lifecycle management and reporting of both Waterfall and
Agile Projects.
Creating Story/LUW:

- EPIC, Story (for Agile delivery) or LUW (for TDP/IR delivery) work item has
to be created by IR/LUW owner or Build Lead.
- For Agile model, EPIC work item creation will be the first step as EPIC
association is mandatory for any story.

EPIC:
Story:
We would need to create story for each BE so that roll back option will be
easier. If an iteration has 3 BEs impacted, then we would need 3 stories.
- Once the IR owner/Build lead gives the story number, developers can start
creating the task for the same.
- Set the parent as Story as below and click on Save.
Creating Task:

- Developers should create task to check in their deliverables.

- Create one Task to check in all your document updates and another task to
check in the Code.

- Task created successfully.

- Note: Always update the version history of the archive file for the
components which requires to be deployed.
- The modified files will be shown in the pending changes tab under
unresolved folder as shown below.
- Right click on the file -> Check-in -> New Change set.

- Now the file will be shown under the Outgoing folder.

- Enter the comment and click on Associate Work Item.
- Associate your task number for the change set and click on Ok.
- You will see the Task details prefixed your comment as in screenshot below.
- The changes are now in your repository workspace.
- To deliver the changes to the main stream, you would need to right click on
the change set and say ‘Deliver’.

- To check the changes are delivered to the correct stream, follow the below
steps.
1. Open the task which you used to check in the files. Right click on the
change sets and select Locate Change sets as below.

2. Select all the change sets and click on add stream to select the stream.
3. On clicking Ok, you will see how many changes has been delivered to
the stream (ER1311) . 3 change sets are not delivered as per the below
screenshot. You would need to check and resolve the issue by checking
in the files again.

Note: If you don’t want a change set to be delivered to the stream, then
please remove the change set from your task. Remove button will be
enabled only for the developer who created the change set.
- Once the changes are delivered, rest of the developers in the team will be
receiving a notification in RTC.
- In the pending changes tab, under Incoming folder they will be able to see
the recent file delivered to the stream.

- Right click -> Accept.

- Note: If the same file is being modified by the developer, then it will show
as conflicts. Then we need to manually do a merge and deliver again.
4. DARP SEED
According to DARP solution, a separate SEED environment – DARP
DOMAIN will be maintained. This environment will just maintain the
dependency between components. No global variables will be
maintained in the SEED configuration for DARP.
Below are the 2 DARP SEED Domains:
 DARP-001
 DARP-002

The SEED domains have to be used for alternate releases. For eg: if 1311 uses
DARP-001 then 1402 should use DARP-002. This mapping of SEED domain for
releases should be communicated to DevOps team so that they make
necessary configurations before starting any deployment of that release.

Example:

ER1311 –> DARP-001 (till 1402 goes Live this should be tagged)

INDEP release (after ER1311 production) -> DARP-001 (since it is an

addition of impacts to 1311 we have used the same DARP domain as 1311)

ER1402 -> DARP-002 (till 1404 goes Live)

 5. RBF DEV Deployment:
The RTC eclipse client is having Build Forge development client that enables user
to trigger the project. Developer can login the RBF console and trigger the project
from Eclipse UI.

Plugin Installation:

- Open Eclipse.
- Click on Help -> Install New Software.

- Enter the below URL as mentioned in the screenshot below and proceed
with the Next steps to complete the installation.
http://ideazz-rbf.in.telstra.com/prism/eclipse/updateSite/site.xml
- If you are not able to access the above URL, then make the below entry in
your host file (C:\Windows\System32\drivers\etc\hosts), restart your
eclipse and try again.
58.162.68.220 ideazz-rtc.in.telstra.com
58.162.68.221 ideazz-rbf.in.telstra.com

- Click on Next to install the Plugin successfully.

- Click on Window-> Open Perspective -> Other..

- Select the Build Forge icon and click Ok.

- After opening the view, Right click in the ‘Console Explorer’ and click ‘New
Console’.
- Provide the values as shown in fig. use your RTC username and password to
login.

- User will see list of projects under the console connection after successful
connection.
- If the deployable component is new, then make sure the deployment config
file is placed in RTC before triggering the DEV deployment. It is the Devops
team’s responsibility to place the deployment config file based on the
Application configuration ESR that factory provide to TA and Devops.
- Triggering the project TIBCO_DEPLOY_DEV deploys the DEV stream artifacts
in the DEV environment.
- Right click the TIBCO_DEPLOY_DEV and click Start this Project.
- In next screen provide the 3 parameter as mentioned below and click Ok.

 DeployableComponent : The name of the component that need to be

deployed on DEV environment. The text is case sensitive.
 RELEASE_ID: the release id of the DEV stream for which user need to
deploy. The release id should be like ERXXXX where X is integer and also the
DEV stream respective to the release id should be exists.
 TARGET_ENVIRONMENT: this should be like DEVX where X is integer.
Environment value other than DEV will fail the deployment.
- Login to RBF console using RTC credentials.
https://ideazz-rbf.in.telstra.com.au:9443/rbf-services/LoginServlet
- Click on Console tab -> Jobs.
- For each of the TIBCO_DEPLOY_DEV you can see respective PackageTIBCO
and DEPLOYTIBCO project run.
- Result will show as Passed once the deployment is completed.

- If failed during any step, then check with DevOps team

([email protected]) for logs. DevOps team will be
responsible to resolve the deployment issues.
 6. Package and Deployment Request:
Package and Deployment request work items has to be raised by the IR
owner/Build/fix lead for any drops or sync ups through RTC.

These work items have to be created under PA_DEVOPS.

Packaging is based on the story state, so before raising the PR and DR, the story
state should be changed to ‘DEV complete’ for AT drop and ‘Approved’ state in
case of CAT drop.
For eg: if story 1, story 2 state in ‘DEV complete’ and story 3 is in Progress, if we
raise the PR for AT drop, only Story 1 and Story 2 will be packaged and deployed
to AT.

Package Type will be Approved package which is for CAT/SVT/ORT drops and AT
package is for AT drop. Maintenance package is for Production defect fixes.

We need to mention the list of Deployable components in the description tab.

And it is also mandatory to mention the tasks which are expected to be deployed.
In the DR Links tab, set the parent as the PR.
7. Retrofits
All the PROD defects will be fixed in the maintenance stream, and the
code has to be retrofitted to DEV stream of the future release. The
retrofit work item should be moved to Approved stream as the next DEV
stream cut will be taken only from Approved stream of the current
release.
 8. Naming convention for Work items:
Work Item Naming Convention
EPIC EPIC: CCB-EAI-<<ERXXXX>>-<<IRXXXX>>
Eg: EPIC: CCB-EAI-ER1311-IR9207
STORY STORY: CCB-EAI-<<ERXXXX>>-
<<IRxXXX>>-US<XXX>-<<BE name>>
Eg: STORY: CCB-EAI-ER1311-IR9207-
US466-ModifyServiceRequest
TASK TASK:CCB-EAI-<<ERXXXX>>-
<<IRXXXX>>-Iteration<<no>>-US<XXX>-
<<BE name>>
Eg: TASK: CCB-EAI-ER1311-IR9207-
Iteration1-US466-
ModifyServiceRequest
Package Request PR:CCB-EAI-<<ERXXXX>>-<<IRXXXX>>-
Iteration<<no>>-US<XXX>-<<Env>>
Drop <<No>>
Eg: PR: CCB-EAI-ER1311-IR9207-
Iteration1-US466-CAT drop 1
Deployment Request DR:CCB-EAI-<<ERXXXX>>-<<IRXXXX>>-
Iteration<<no>>-US<XXX>-<<Env>>
Drop <<No>>
Eg: DR: CCB-EAI-ER1311-IR9207-
Iteration1-US466-CAT drop 1
 9. Template for Deployment Request
Below is the sample format for raising DRs to DEVOPS team.
Stream R1311 DR ID 27972

Requested By Divya Requested Date 3/10/2013

Target List of deployable DDCTargetSyncService

SIT4
Environment components AccountInvoiceInquiry

Package Request Id 27970 Package Status New

Story/LUW/Defect Complete Development

27929 Story/LUW/Defect Status
id (AT)/Approved (CAT)

Task Id 27935 Task Status Done

EMS Refresh ESR: 27936

ESRs
Smart mapper update ESR: 27937
10. POST DARP-TIBCO DEVOPS/FACTORY
RESPONSIBILITIES:

10.1 EMS Objects:

 TIBCO factory should raise an ESR/DR to DevOps team if there is new EMS
Object creation/update required as part of their development.
 DevOps team route the ESR/DR to TA/TSD team to update the TA423
document and generate appropriate EMS scripts.
 Factory team should ask TA team to provide the pre-requisite ESR to
DevOps team before raise Deployment Request
 DevOps should execute that pre-requisite EMS Refresh ESR during before
deployment.

10.2 DeploymentConfiguration XML creation:

 TIBCO factory has to raise an ESR/DR to DevOps team whenever there is a

new deployable component added or updated any existing deployable
component configuration properties as part of their development.
 DevOps team route the ESR/DR to TA/TSD team to update the TA423
document and generate appropriate DeploymentConfiguration XML file.
 DevOps team has to take the deployment configuration xml file and check
in to RTC EAI DevOps Stream

10.3 SmartMapper Error Code Update in TIBCO Admin GUI:

 TIBCO factory has to raise an ESR to DevOps team to update the newly
added SmartMapper error code in TIBCO Admin GUI.
 DevOps team has to update the SmartMapper error code in TIBCO Admin
GUI as per ESR during deployment.
10.4 SQL files Deployment:

 TIBCO factory has to raise an ESR to DevOps team to execute all

development impacted .SQL files in respective target database.
 DevOps team has to execute the .sql scripts as per ESR instructions.

10.5 DARP-SEED Domain:

 TIBCO factory has to raise a request to DevOps team to inform the current
release specific DARP SEED domain.
 DevOps team has to update the property file with the current release
specific DARP SEED domain name and check in to RTC location
CBT_DEVOPS_EAI\CBT_DEVOPS_EAI\AutomatedDeployment\Scripts\
SEEDandBENameTranslation.properties.

10.6 Clean-up in RTC stream:

 TIBCO factory team has to raise a request to DevOps team to create

release specific TIBCO RTC stream.
 DevOps team will create release specific TIBCO RTC stream and
communicate the same to factory team.
 As a first step TIBCO factory has to delete all files which is under this RTC
location CBT_TIBCO_SYSCMN/DeploymentDetails before starting
development work.

10.7 Retrofit PROD defects

 TIBCO factory team has to raise a request (ESR) to DevOps team for
retrofitting the PROD defect fix code from maintenance stream to the
future DEV stream.
 Points To Ponder

 SEED DARP domain configuration communication to Devops team

once after the stream creation.

 Repository workspace should have the stream in the Flow Targets.

 Create one EPIC for an IR.

 Create separate Story for each BE so that Roll back will be easier.

 Create one task for Code update and another task for doc update.

 Update archive file for the deployable components.

 Update archive file for the Arch Comp services

(ErrorHandlingServices, ResubmitService etc) for all releases.

 Remove unwanted change sets (not required to be delivered to

stream) from task.

 Story status should be ‘DEV complete’ for AT drop and ‘Approved’

for CAT and other environments.

 Provide deployable components, task and story details in PR and

DR.
 Raise PR (AT and Approved package) for all the retrofit tasks and
stories and raise DR if applicable to be deployed for the release.

 Do not create ESRs for .xml Config file updates.

 Create ESRs for all SQL updates.

 After the AT drop, story status should be ‘AT package Created’, if

not ask Devops team to update.

 After the CAT drop, story status should be ‘Approved package

Created’, if not ask Devops team to update the status.