Installing IBM Rational Build Forge V7.02 on UNIX and Linux
IBM® Rational® Build Forge® Servers Globally distributed development
This module covers the basics of Globally Distributed Development for IBM Rational Build Forge Version 7.0 and above. This module assumes users are familiar with IBM Rational Build Forge basics. For a primer on Build Forge, exit this module and first review the Introduction to Build Forge module, then continue with this more advanced topic.
Objectives
Objectives Know what globally distributed development (GDD) is in Build Forge and its benefits Understand the architecture of GDD in Build Forge
This module provides an overview of the benefits of Globally Distributed Development (GDD), and the problems it is meant to bypass. It also discusses the architecture of GDD.
What is GDD?
What is GDD? GDD is the Build Forge mechanism for working around wide area networks (WANs). Performance problems develop around sending large amounts of information between very distant locations. For example, there is a Build log generating 5 MB of data, and an agent in India wants to send that data back to a console in North America. However, delays and general network problems impair the transfer. Extraneous data should not be sent, particularly when giving tasks to agents.
GDD is a feature added to Build Forge to relieve problems experienced on widely distributed Build Forge configurations. Problems occur in situations where the agent is geographically distant from the console. There are many inconsistencies with performance, as the Build Forge engine and Agent have trouble staying in sync over the Wireless Area Network (WAN). The solution involves finding a way to reduce the amount of traffic between the Agent and the Engine to minimize the exposure to WAN performance inconsistencies.
The problem
The problem C NA India A Build request - small and easily sent Build artifacts and build logs - This can vary greatly in size
This is a diagram of the problem before GDD is implemented. The Build request is small, and not necessarily affected by distance. The problem emerges when the results need to be sent back to the console. In some cases, this can be hundreds of pages of log files, or large files generated at the Agent. If there are any problems on the WAN during the transmission of that data, bad data will end up in the database.
Solution
Solution Rather than sending back the entire build log and artifacts, keep them where they are generated. Install an additional engine in the remote location, and store the build log information there. Keep the build configuration information in the main management console. Data from the agent does not go over the WAN, but stays in the same location as the agent.
The solution to this situation is to bring the engine closer to the Agent. To accomplish this, add additional engines to the configuration, which will act as local engines for the Agent. This allows the remote engine to store just the project configuration data, leaving the local engine to store the potentially large amount of data that comes back from the Build request. The problem transmit is kept local, thus avoiding the problem.
Solution diagram
Solution diagram C NA India A Build request C Build logs and artifacts
This diagram shows the new behavior after GDD is set up. The Build request is still sent from the remote console. However, once the agent runs and completes the task, the Build Logs and files are kept local, as they are only sent to the local Console, and not to the remote one. When a user wants to access those logs or files they can do so from the remote console, and the request is forwarded to the local console where the data actually resides. To the user, there is no difference between this and a non-GDD environment.
Benefits
Benefits Through GDD, Build Forge regionalizes the engine processes. GDD remedies performance problems associated with relying on network traffic over long distances. The main management console can be configured to fail over to a secondary site if necessary. GDD should not be confused with clustering. Clustering is two engines pointing at the same database, while GDD is a totally separate Build Forge installation with its own database.
By implementing GDD, Build Forge allows users to regionalize their processes without penalty for having the agents geographically remote. The data stays local, and the WAN is not overburdened with Build Forge traffic. Also, Build Forge allows those secondary consoles that exist in the other locations to be set up as failover consoles, as they are Build Forge installations complete with their own engine and database. This is different than clustering in Build Forge. Clustering is when two engines point to a single database. This improves performance by balancing the load from a single database across multiple engines. In a GDD environment, each engine has its own engine and database, and improves performance by keeping data transmits local.
Summary
Summary GDD is the mechanism that Build Forge uses to break down an architecture into regional sections. GDD improves performance for widely distributed agents.
In summary, GDD is Build Forge’s way of breaking large architectures into regional chunks. This breakdown improves performance by keeping the potentially large data transmits local to the agent that is running the Build.
Feedback
Feedback Your feedback is valuable You can help improve the quality of IBM Education Assistant content to better meet your needs by providing feedback. Did you find this module useful? Did it help you solve a problem or answer a question? Do you have suggestions for improvements? Click to send e-mail feedback: mailto:iea@us.ibm.com?subject=Feedback_about_RBF_Module6_BuildForgeGDD.ppt This module is also available in PDF format at: ../RBF_Module6_BuildForgeGDD.pdf
You can help improve the quality of IBM Education Assistant content by providing feedback.
Trademarks