Centralized change and configuration management for geographically distributed development

When globally distributed teams transition development projects to a centralized change and configuration management infrastructure, they can collaborate more efficiently to create valuable deliverables. The newly published IBM Publication Center feature, Geographically Distributed Development: Centralize Change and Configuration Management, describes how to make this transition. This resource provides instructions to plan for centralization and to regionally deploy IBM® Rational® ClearQuest® and IBM Rational ClearCase® environments to a centralized regional hub.

Mats Göthe (mats.gothe@se.ibm.com), Solution Architect, WSO2 Inc

author photoMats Göthe, PhD, is a Solution Architect on the Collaborative Lifecycle Management team, focusing on solutions for IT and systems. Göthe has worked for IBM Rational for over 19 years in various positions, including as a development manager for IBM Rational Rose in Sweden, Rational technical sales and service manager in the Nordic region, and Ericsson Corporate Account team member. Göthe has authored several Collaborative Application Life Cycle Management publications, and holds a doctorate in physics from Uppsala University, Sweden.



21 September 2010

Also available in Chinese Spanish

Centralized change and configuration management

As software delivery organizations expand globally, many companies now use a geographically distributed development (GDD) approach to effectively manage acquisitions, partnering, and outsourcing. Project teams in globally distributed organizations must collaborate to deliver business-critical applications under compressed timeframes within cost constraints. An answer to these challenges is the IBM Rational Global Development and Delivery solution, which combines Rational ClearCase and Rational ClearQuest capabilities. With this solution, software development teams can manage change and configuration across distributed geographies. The solution also offers Rational ClearCase Multisite and Rational ClearQuest Multisite that replicateand synchronizerepositories across organizations. Teams can use these capabilities and repositories to collaborate and to enable a global software supply chain.

Many project teams that practice GDD choose a development infrastructure topology by using ClearCase and ClearQuest to support and map their organizational structure and needs. The ClearCase and ClearQuest environments are deployed to all development sites by using ClearCase and ClearQuest Multisite. In addition, the development infrastructure often must contact development partners and service providers to enable sub-contracting or outsourcing processes. While this deployment pattern tightly integrates the development team and workflow, it increases the administration cost of a distributed development platform.

To address these issues, the tight mapping of the organizational distribution and the development infrastructure topology is separating. By centralizing the development infrastructure, organizations can rapidly respond to changing business needs and scale and source projects, while lowering the total cost of development. A centralized change and configuration management approach is not only more cost-effective, but also enforces consistent technology standards and best practices across the enterprise.

To learn more about this subject, see Geographically Distributed Development: Centralize Change and Configuration Management in the IBM Publication Center. That report provides planning guidance and instructions to centralize your change and configuration management tools for globally distributed teams. The report was written for organizations that use a ClearCase and ClearQuest distributed deployment platform and Multisite and that want to consolidate their infrastructure and administration by adopting centralized development services.


Guidance for centralization: Adoption route scenario

The content in the Geographically Distributed Development: Centralize Change and Configuration Management information center is based on a methodology for scenario-based adoption routes. The methodology was developed by the IBM Advanced Scenario Lab. An adoption route is a prescriptive pattern that embodies the best practices to deploy a collection of products in a particular business context. Adoption routes are divided into phases that deploy a subset of proposed products so that value is delivered in each phase.

The adoption route for centralize change and configuration management provides a phased approach for migrating to ClearCase and ClearQuest repositories. The approach starts by moving to a regional hub and deprecating local servers. Then, new wide area network (WAN) clients are adopted by regional project teams. The approach also supports improving scalability at the regional hub by load balancing across the centralized change management servers.


Centralized change and configuration management scenario

The adoption route scenario starts from a generalized development infrastructure topology, that is, the As-Is topology. This As-Is topology has both the logical aspects of deployed tool integrations and the physical aspects of the server platform distribution.

The following general characteristics apply to the As-Is environment in the scenario:

  1. Global development is performed at multiple, connected regional sites. The sites range in size from small regional sub-sites with a few development team members to large regional hub sites with a range of roles in the development and IT organization.
  2. Some development projects span multiple sites, while others run locally at one site.
Figure 1. The As-Is topology in the adoption route scenario
Graphic shows the global array of development sites.

In the As-Is topology, the development infrastructure is deployed as follows:

  1. Regional teams at regional sites use ClearCase and ClearQuest, with clients and local replicas for development and delivery.
  2. Regional sites synchronize their repositories to other regional sites based on project dependencies.
Figure 2. The physical distribution and integrations in the As-Is topology
Picture depicts a multisite repository replication.

The adoption route scenario prescribes three transition phases for your organization: the As-Is topology, the new To-Be centralized topology, and shared project workflows.

The To-Be topology has these characteristics:

  • One or more regional sites form regional hubs. The number of regional hubs and regional sites that a regional hub services depends on the size and needs of the organization.
  • Regional hubs serve regional sites with shared development services by using centralized repository servers and shared project roles. Repositories at regional sites are migrated to the regional hub.
Figure 3. The To-Be topology in the adoption route scenario
Picture shows teams connecting to regional hubs.

The development infrastructure in the To-Be topology has these characteristics:

  • Regional teams at regional sites connect to regional hubs by using WAN or web clients. Team members, such as developers who need integrated ClearCase and ClearQuest workflows, use the ClearCase Remote Client. Roles that require simple ClearQuest access can use ClearQuest Web.
  • Multiple change management servers connect remote users to the centralized ClearCase and ClearQuest repositories.
  • Load balancing distributes network traffic and delivers scalability.
  • Regional hubs are interconnected by using ClearCase and ClearQuest environment Multisite replication.

Figure 4 shows the new To-Be physical topology. In the figure, a centralized region has been established. The regional teams are composed of local team members (in orange) and contributors from the regional hub (in blue) for shared functions. The figure also shows that some regional teams, or projects, that stay on the existing distributed development infrastructure are not affected by centralization. Such teams can, when project schedules permit, proceed and adopt the centralized topology.

Figure 4. The physical distribution and integrations in the To-Be topology
Graphic shows teams connecting at the regional hub.

Phases to adopt centralization

The adoption route scenario for centralized change and configuration management has three major phases. In each phase, the benefits of centralizing business operations increase, so that value is added incrementally.

In phase one, the organization plans and prepares to centralize. During this phase, regional hubs are selected. Regional hub sites must be able to support the increasing demands on IT and development infrastructure management, such as network load, access security, server capacity, and development project administration. In this phase, the centralized infrastructure is installed at the regional hub. In addition, the regional sites participating in the centralization area are identified. These sites will transition their local repositories to the regional hub and deprecate their local ClearCase and ClearQuest servers. Users at the regional site migrate from local area network (LAN) clients to WAN clients and access project assets at the regional hub. When regional teams are centralized, projects can share common roles and assets, such as tool and project administrators.

In phase two, the regional hub is upgraded to the latest development platform and change and change management tool versions. By making this upgrade, teams can utilize product improvements in WAN client capabilities and CM server performance and administration.

Phase three establishes scalability at the regional hub by providing load balancing capabilities for ClearCase and ClearQuest change management servers. The load balancing capabilities are provided by IBM WebSphere® Application Server Network Deployment. Supporting an increasing number of regional sites might also require more ClearCase and ClearQuest servers to be deployed in the centralize change and configuration management topology.


The Geographically Distributed Development: Centralize Change and Configuration Management information center

The Geographically Distributed Development: Centralize Change and Configuration Management information center provides details about the centralize change and configuration management adoption route. The information center is organized in two parts: the solution planning guide and the development topology guide. The latter contains the three centralization adoption phases. You can access the information center online or in downloadable PDF files.

Figure 5. The Geographically Distributed Development: Centralize Change and Configuration Management information center provides instructions to adopt a centralized development infrastructure by using ClearCase and ClearQuest
Screenshot shows the information center.

Larger view of Figure 5.

The adoption route phases are presented in the information center in an instructional format, based on best tool deployment practices and linked to current best support practices with related product support tech notes. Each phase is organized by the activity and task performed on servers or clients in the regional hub or sites. Tasks are organized by machine, in the physical topology, and by tool in the logical topology. While the adoption route is composed as an end-to-end scenario, you can apply only phase one to achieve regional centralization, or re-apply phase one incrementally to centralize regional teams over time. For smaller regional hubs that use the IHS load balancing capability that is provided with ClearCase and ClearQuest phase three is optional.

The information center contains details about the phases. In phase one, the following centralization activities are performed:

  1. Prepare for centralization: This activity involves centralization planning, creating a centralized installation manager repository for tool provisioning, and upgrading the change management servers at the regional hub.
  2. Centralize repositories: This activity involves backing up repositories, migrating repositories to the regional hub, and stopping multisite replication to the regional site.
  3. Upgrade clients at regional sites: This activity involves upgrading the client software that the project team uses. Also, the team migrates from dynamic views to web views.

In phase two, these administration activities are performed:

  1. Upgrade servers at the regional hub: This activity involves uninstalling version 7.0.1 of the ClearCase and ClearQuest server and re-installing version 7.1.1.
  2. Upgrade client at the regional hub: This activity involves uninstalling version 7.0.1 of the ClearCase and ClearQuest client and re-installing version 7.1.1.

In phase three, these administration activities are performed:

  1. Configure load balancing: This activity involves installing the WebSphere Application Server Network Deployment version 7.0 and configuring the load balancing capability for the environment.
  2. Upgrade client configurations: In this activity, the regional team changes the URL properties in ClearCase Remote Client and in ClearQuest Web to connect to the change management servers through the load balancer server.

Summary

Many organizations work in a geographically distributed development environment. For global software development and delivery organizations, collaboration and team workflows are key to overcoming the barriers of distance and time-zones, conflicting in-house processes, knowledge- and work-transfer issues, and issues of project artifact ownership. Common processes, tools, and reporting are critical in overcoming these risks. Software development organizations must strive to improve project agility and achieve better cost containment. Such organizations can benefit greatly by using a centralized change and configuration management model for GDD.

The Geographically Distributed Development: Centralize Change and Configuration Management information center provides guidance for regional teams that use ClearCase and ClearQuest to migrate to a centralized regional hub topology. With this strategy, organizations can reduce costs in tool administration and improve team productivity and response times to deliver global projects.


Acknowledgements

Special thanks to the authors of the Geographically Distributed Development: Centralize Change and Configuration Management information center, and to the IBM Scenario Analysis lab. In alphabetical order: Vishal Anand, Sujeet Mishr, Alok Singh, Mahesh Sundaram, Kaylee Thomsen and Saurabh Tiwari.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=524044
ArticleTitle=Centralized change and configuration management for geographically distributed development
publish-date=09212010