3184Optimizing StarTeam for

Distributed Teams

Randy GuckChief Scientist, DSP

Borland

Overview

The distributed team dilemma– The challenge– The dilemma– Advantages and concerns of

replication– Advantages and concerns of

centralization

Overview

Distributed teams the StarTeam way– Optimizations for remote teams

• Client-activated options• New features for StarTeam 7.0

– StarTeamMPX• Turning the network inside-out• New features for StarTeam 7.0

– StarTeam Import/Export Manager– The future of distributed teams

The Distributed Team Dilemma

Centralize or Replicate?

The challenge– Teams are increasingly becoming

distributed• Global companies, out-sourcing, etc.

– Geographically dispersed teams need access to the same lifecycle artifacts

• Variation: Sometimes network issues raise the same issues for “network near” teams

Centralize or Replicate?

The dilemma– Should repositories be centralized and

access provided to all team members? or…

– Should repositories be replicated to remote locations for local access?

Replication

Advantages– Network-near performance for remote

teams– Remote teams remain productive

when the root server is inaccessible

Replication

Concerns– High administrative cost for constant

replication– Artificial merge conditions introduced– Replication demands its own

bandwidth and reliability– High product cost (extra hardware,

licenses, DBAs, …)

Centralized Repositories

Advantages– Maximum administrative control

• Users, groups, security• Workflow, customization• Product versions and upgrades

– No artificial merge conditions– Lowest overall cost (e.g., admin,

servers, H/A features in one place)

Centralized Repositories

Concerns– How do remote teams get

performance?– How do remote teams remain

productive during network brownouts?

The StarTeam Solution

StarTeam promotes centralized repositories– Highest control/security, lowest cost

How do remote teams remain productive?– Optimizations for remote users– Innovative technology for remote teams– Intelligent “push caching”, reducing the

need to touch the network

Replication not needed for distributed teams!

Optimizations forRemote Teams

StarTeam C/S Architecture

StarTeamClient

StarTeamClient

VaultVault

StarTeamServer

DB

Command API

StarTeamClient

All information is pulled by

clients using a request/reply

command API

Optimizations for Remote Teams

Command API compression

Reduces network traffic up to 80%

Optimizations for Remote Teams

Delta check-outs for faster check-outs

New for 7.0: Cross-platform client support

Optimizations for Remote Teams

Auto-reconnect: Connection loss resiliency

New for 7.0: Cross-platform client support

StarTeamMPX:Turning the network inside/out

StarTeamMPX Architecture

StarTeamClient

StarTeamClient

VaultVault

StarTeamServer

DBMessageBroker

Event publish stream

StarTeamClient

Updated objects are pushed to

clients, preventing poll and refresh

requests, reducing network demand

StarTeamMPX Profiles

Deploy a Message Broker in each geographic region with > 5 users– Note: Maximum 10 Message Brokers

Create an MPX profile for each Message Broker– e.g., “Denver MPX Profile”

Set the “client default” profile to the one most users will use

Hub-and-Spoke Configuration

MB

MB

MB

MB

ST Server and MB

Using StarTeamMPX

First enable it…

– Automatic refresh options take advantage of update messages

Using StarTeamMPX

…then choose the appropriate MPX profile

New for 7.0: MPX Cache Agent

StarTeamClient

StarTeamClient

VaultVault

StarTeamServer

DB

EncryptedCache

EncryptedCache

MessageBroker

CacheAgent

File publish stream

Check-outrequests

The Cache Agent is trickled charged

with file contents, providing an alternate

check-out source for remote clients.

MPX Cache Agent

Advantages– New files are broadcast once– Unicast and multicast broadcasting– Multiple Cache Agents can be

deployed to assist remote locations– Cache Agents are trickled-charged

automatically (“push caching”)– Multiple StarTeam server support

MPX Cache Agent

Advantages– Files are encrypted in transfer and

storage– Cache Agent-aware clients can check-

out from any Cache Agent• Clients can be configured to auto-locate

the nearest Cache Agent

– Up to 98% of outbound traffic removed from StarTeam server

MPX Cache Agent

Advantages– Remote users receive network-near

check-out performance• Bulk/parallel check-out faster than normal

check-out

– Traffic reduced over long wires; more bandwidth for other apps

– Server “availability window” reduced for large file check-outs

Stacked Cache Agents

StarTeamClient

StarTeamClient

VaultVault

StarTeamServer

DB

EncryptedCache

EncryptedCache

MessageBroker

RemoteCacheAgent

RootCacheAgent

Alternate check-out path

Catch-up/forwarded requests

Tiered Cache Agents

Advantages– Special root Cache Agent provides

forwarding headwater– Downstream Cache Agents can

forward request “misses” to root Cache Agent

• All Cache Agents in the “stream” are charged along the way (like traditional “demand” caching)

Tiered Cache Agents

Advantages– Downstream Cache Agents can catch-

up from root Cache Agent after network outages

• Cache Agents know how to recharge/synchronize, regardless of clocks, topologies, etc.

• New Cache Agents can “pre-charge” from root Cache Agent

Tiered Cache Agents

Advantages– Cache Agents can be tiered in any

configuration; any # of levels– Cache Agents auto-locate the root

Cache Agent; minimal configuration– New remote Cache Agents can be

added to the cloud dynamically; auto-locate clients will automatically find and use

Cache Agent-Aware Clients

Cross-platform Client

Cache Agent-Aware Clients

Bulk check out (BCO) command-line utility– Alternative to “stcmd co” command– Cache Agent-aware– Switches to regular check-out if

needed

Example:bco -p "user:pw@prod1:49201/Project1/View1/srcfiles"

-useCA autolocate -cfgl "6.0.1" -is -o -filter IO "*.java"

Distributed Cache Agents

MB and CA

MB and CA

MB and CA

MB and CA

ST Server, MB,and root CA

StarTeam Import/Export Manager

Is Replication Ever Needed?

Most cited reasons for replication:– Scalability

• Team size exceeds server capabilities• Not a valid reason for StarTeam!

– Distributed teams• Software doesn’t support remote teams• Not a valid reason for StarTeam!

Is Replication Ever Needed?

Most cited reasons for replication:– Security issues

• Establish a virtual firewall between teams• Not a valid reason for StarTeam!

– Connectivity• No physical network with a remote team• The most valid reason for needing

replication

New for StarTeam 7.0:StarTeam Import/Export Manager

Features:– Separate export, transfer, and import

phases– Full and incremental export/import– Scoped processing: server, project,

view, folder hierarchy– Ideal for project transfer

Import/Export Basic Flow

XML+archive

image

On-line oroff-line transfer

SourceStarTeam

Server

Export

XML+archive

image

Read-onlyprocess

TargetStarTeam

Server

Import

Local updateprocess

StarTeam Import/Export Manager

Ideal for copying critical projects from one repository to another

Bi-directional flows can be set-up

Can be used to “move” projects to new servers (e.g., for rebalancing)

Note: Copied projects are not identical to the original– E.g., CR numbers may change

The Future of Distributed Teams

Where are we headed?

Occasionally-connected/mobile teams– Read-only caching of all artifacts– Client “auto save” of view contexts– Updates queued and resynched when

connectivity is restored• Think email client/PDA metaphor• Merge conditions resolved during sync

Summary

Optimize StarTeam for distributed teams– Centralized repositories– Command compression, delta check-

out, auto-reconnect– StarTeamMPX, distributed Cache

Agents, CA-aware clients– StarTeam Import/Export Manager

when replication is the only choice

Questions?

Thank You

3184

Optimizing StarTeam for Distributed Teams

Please fill out the speaker evaluation

You can contact me further at …randy.guck@borland.com