Optimizing Borland Starteam for Distributed Teams

Optimizing Borland® StarTeam® for distributed teams The best techniques for supporting distributed teams A Borland White Paper By Randy Guck, Chief Scientist Borland Software Corporation January 2005 Optimizing Borland® StarTeam® for distributed teams Contents Overview ............................................................................. 3 The distributed team dilemma: Centralize or replicate? .......... 3 Distributed teams and network concerns .............................................................................. 3 Replication: Advantages and concerns ................................................................................. 4 Centralized repositories: Advantages and concerns.............................................................. 5 Is replication dead? ............................................................................................................... 7 Distributed teams the StarTeam way ..................................... 7 Standard client/server features for distributed teams ............. 8 Command API compression ................................................................................................. 9 Delta checkout .................................................................................................................... 11 Auto-reconnect.................................................................................................................... 13 StarTeamMPX: Turning the network inside-out ......................15 StarTeamMPX Cache Agent: Distributed file caching..............20 Basic Cache Agent architecture .......................................................................................... 20 Stacked Cache Agents......................................................................................................... 23 Cache Agent-aware StarTeam clients ................................................................................. 25 Using Cache Agents with the Cross-Platform Client...................................................................... 26 Using Cache Agents with the bulk checkout utility........................................................................ 27 StarTeam Import/Export Manager .........................................28 Summary: The world according to StarTeam..........................32 Glossary .............................................................................34 References .........................................................................36 2 Optimizing Borland® StarTeam® for distributed teams Overview Software development teams are increasingly becoming spread around the globe. Organizations are leveraging new talents, time zones, and tools made possible by a networked world. If you work on a distributed team, how should you manage lifecycle tools with shared repositories such as Borland® StarTeam®? If you centralize files, change requests, and other application lifecycle management (ALM) artifacts, how can you address performance and reliability? If you replicate artifacts to distributed sites, how do you handle synchronization and conflicts? This white paper describes the best techniques for supporting distributed teams with StarTeam. The problems with replication are discussed, and the case for supporting your organization with centralized StarTeam repositories is made. Features with which you can optimize StarTeam for distributed teams, including new features introduced with StarTeam 2005, are described. These features address responsiveness, limited network bandwidth, and even unreliable networks. The distributed team dilemma: Centralize or replicate? This section examines the basic dilemma that organizations face when deploying a repository- centric client/server application such as StarTeam. Basically, the question boils down to: Can you centralize the repository and provide adequate performance to remote teams? Or should you deploy multiple repositories and attempt to replicate and synchronize between them? Distributed teams and network concerns So, your organization has decided on StarTeam to manage core development processes. Congratulations! But now you have to figure out how to make StarTeam work for your distributed team. You have one group in Chicago, another in Europe, and a third group in 3 Optimizing Borland® StarTeam® for distributed teams India. All of your developers require access to the same projects, views, files, change requests, and tasks. And, to complicate matters, the transatlantic VPN connection between sites isn’t highly reliable; there are occasional outages ranging from minutes to hours. How do you deploy StarTeam to maximize distributed team productivity while avoiding administrative headaches? Geography often creates its own challenges, but sometimes network issues arise even when distance is not a factor. In sufficiently large organizations, LANs and WANs can experience periods of congestion or instability, raising similar issues as those experienced by geographically dispersed teams. In both cases, team members need access to the same application lifecycle artifacts but are faced with network latency, bandwidth, and reliability issues. Would you rather centralize your repository or distribute multiple copies and synchronize them? Let’s examine both approaches in more detail. Replication: Advantages and concerns Some repository-centric systems recommend that the way to address distributed teams is to replicate the repository between remote sites and continuously synchronize them. By providing a “network near” repository instance, remote teams experience two primary benefits: • Performance: Accessing a local repository over a local, high-speed LAN generally performs better than accessing the same information over a slower, long-distance network. • Accessibility: Except for the inability to synchronize, a local repository will be unaffected by the unavailability of long-distance access. Hence, local teams can access artifacts even when the WAN, VPN, or ISP connection is down. However, organizations that attempt to implement replication eventually discover that there are many costs, some of which are not obvious at the outset: 4 Optimizing Borland® StarTeam® for distributed teams • Administrative costs: Each replicated server requires its own administration, backup, monitoring, and other maintenance. You might find that you need repository, security, database, and other expertise at each remote site. • Artificial merge conditions: Replication forces artificial merge conditions in cases in which you wouldn’t otherwise want it. Two developers working on the same file might introduce conflicting changes. Whereas they might otherwise avoid merge conflicts via locking, with separated repositories, they will not realize that they are introducing a conflict. This creates more work during synchronization, lengthening the development cycle. • Network demands: Replication creates its own bandwidth and reliability issues. As more replicated repositories are deployed and project sizes grow, network demands increase (which is the reason that replication was deployed in the first place!) And if available bandwidth can’t keep up with the constant replication…think house of cards in a strong wind. • Other costs: Replication means extra server hardware, licenses, redundancy, backup media, and more. But suppose a centralized repository performed well even over long-distance, bandwidth- constrained networks? What if developers could use locally cached data, with less reliance on online access to the repository? What if you could get replication’s benefits without the cost? Centralized repositories: Advantages and concerns Most organizations prefer centralized repositories. Why? Among the advantages of centralized repositories: • Overall cost: With a centralized repository, your most expensive infrastructure costs—servers, high-capacity storage, high availability/failover support—are deployed in one place. Furthermore, your administrative expertise can be concentrated in one place. 5 Optimizing Borland® StarTeam® for distributed teams • Security control: With a centralized repository, it is much easier to perform administrative security tasks such as user and group management. • Process control: Workflow rules and repository customizations can be managed in one location. Artifacts can be locked in one place, when needed, to synchronize updates across the entire enterprise. • Backups: Comprehensive backup procedures can be more easily managed when they occur in a central location. Recovery and disaster-recovery plans are easier to manage with fewer “moving parts” in the overall infrastructure. • Upgrade control: New product versions can be installed and the repository can be upgraded at a single installation. At the same time, centralized repositories introduce challenges for distributed teams. There are two primary concerns: • Performance: How can you provide adequate performance to remote teams, which might be constrained by network bandwidth? The more users and the more lifecycle artifacts you have, the higher the demands on long-distance network segments. • Accessibility: The longer the “wire” between two sites, the less reliable it becomes. During a “network brownout”, how do you keep remote teams productive until connectivity is restored? We’ve tipped our hand that StarTeam promotes centralized repositories over replication. Just to whet your appetite a bit, here’s an interesting fact: real customer benchmarks have shown that StarTeam’s performance over a global

Load more