The following figure shows the overall topology of an IBM Mobile Development Lifecycle Solution installation.
Along the top of the figure are the desktop systems that are used by members of the team.
Developer desktops are equipped with Worklight Studio and the Rational Team Concert™ Client on a supported Windows, Linux, or Mac OS operating system. Different developers can run different operating systems. In fact, it can be beneficial in many mobile application development projects to deploy various supported operating systems across the developer community. Deploying various operating systems maximizes the team's ability to test on a diverse set of Android, iOS, and other devices. Match the number of Worklight Studio developer desktops to the number of developers on the team.
Testers, project managers, analysts, and other stakeholders who are not developing mobile application code do not need Worklight Studio. They can use their desktops, notebooks, tablets, or any device with a suitable browser to interact with CLM, Worklight Server, and Application Center consoles.
In this topology, the Jazz™ Team Server, CLM applications, and databases are deployed to a single server. It is intended for evaluation, demonstration, or training purposes. It is inadequate for typical, production development projects because of the limited scalability of a single server.
This departmental topology is the recommended topology for most mobile application development projects.
In this topology, the CLM applications are deployed to one or more application servers that are sharing a single Jazz Team Server. The databases are managed by an enterprise database management system such as DB2® on a dedicated server. This topology is ideal for mid-sized development teams and projects, and is the recommended topology for all mobile application development projects. However, large projects require the capacity and scalability of the enterprise topology.
In this topology, the CLM applications are deployed to separate application servers, sharing a Jazz Team Server on a separate application server. In addition, the applications and Jazz Team Servers might be clustered. This topology is suitable for large development teams and heavy development workloads, and is over powered for most mobile development projects.
In this topology, the CLM applications are deployed to separate application servers with separate Jazz Team Servers. This topology might be suitable for diverse development teams that are not required to collaborate together. Collaborative development is a central theme to the IBM Mobile Development Lifecycle Solution; therefore, this topology is not recommended.
At the bottom of the figure are servers that are running Rational Team Concert Build System Toolkit, and the Worklight Server. These two workloads important to the build system.
The Build System Toolkit servers process build requests from Rational Team Concert, and can run on various supported operating system, including Windows, Linux, and Mac OS. Unless you expect the number and frequency of builds to be fairly high, start by setting up only one or two build servers. Additional build servers can be readily installed and configured. If build workloads diminish, build servers can be withdrawn just as readily.
Typical build scripts include tasks for deploying mobile applications, adapters, and native application packages to a Worklight Server and Application Center. As shown in the lower area of the figure, the recommended practice is to install one Worklight Server for use by one or more Build System Toolkit servers.
For more information, read about Building with Jazz Team Build on the Rational solution for CLM information center.
In the middle left area of the figure is an example of a Worklight Server used the team to manage mobile applications, adapters and binaries, but is not used by the build system. Though not required, seting up at least one non-build Worklight Server provides the team with place to deploy, share, and test mobile applications and adapters that is separate from artifacts produced by the automated builds.