In general, I am a “glass half full” person so I try to look for the positives in any situation. There are many things that make using the IBM Rational Jazz platform into an interesting and rewarding proposition for our customers. One of those is being able to access virtually any software development project asset by a URL. You can send this URL to anyone on your project (or even outside your project if guests have read-only access) and that person can click on that URL, authenticate, and start examining that project asset. This is a huge boon to software development! If you think about it, you didn’t send recipient a copy that may be out-dated in minutes, hours, or days, but a link to the live asset in its process context. Its links to other related assets are all “live” and can be used to navigate to the assets providing context to that asset. No more proliferation of outdated versions of assets. No more worries about whether the asset has changed since it was sent to you.
Now with all that said, there are some implications of using URLs to reference project assets that you need to be aware of. If that asset is moved or deleted, you end up with a useless broken link. The current state of the Jazz technology is that you don’t ever want to change or break that link. This is the genesis of the absolute rule that you can not change your Public URL for your Jazz server. You don’t want to break a bunch of asset URLs that have been distributed to project members.
However the IT business is very fluid and customer infrastructure is always changing, growing, morphing into a new way of supporting software development every day. The lifetime of a server system hosting development assets may be as short as two years or possibly as long as five or ten years. Projects may start out with five people and grow to two hundred people over the course of a five, ten or more year lifetime. How do you plan for this public URL that can never change?
From my perspective (and I believe it is a sound “best practice”), the Public URL of a Jazz server should be created with the intent that it be a long-lived logical address to a repository of Jazz hosted assets. This means it is not a physical server name and it is not the system name of an operating system instance running in a cloud or virtual image. The hostname component of the Public URL should be a logical Jazz server name. The example I like to use is jts01.myServerFarm.myCompany.com for the Jazz Team Server and qm01.myServerFarm.myCompany.com for the Quality Management Server.
As for implementation of these servers, it is totally independent of where and on what hardware the server is hosted. Using a DNS entry, you can steer the requests to whatever host name that the server is hosted.
Of course as usual the devil is in the details and it is no
different for the Public URL. The whole
Public URL must not change! This
includes a hostname, a port, and a context root for the Jazz application that
is processing the request. In that vein,
for new installations of the Jazz Team Server the public URL maybe something
like https://jts01.NAjazzservers.ibm.com:9443/jts for its address and a new Change and ConfigurationManagement Server would use https://ccm01.NAjazzservers.ibm.com:9443/ccm for its address.
One of the nicest features of the new Release 3.0.1 version of the Jazz products is that you can host one or more of the applications on the same web application server. This can be done to save on deployment costs (of having all individual servers – one per application) with the understanding that later on, you may want to separate out heavily used applications on to their own servers. There is really very little “routing” that you must change to make this transition happen. Let’s go through an example of a small team’s deployment of the full Collaborative Lifecycle Management capabilities on a single application server and how it can be migrated without breaking any Public URLs to a distributed set of servers when the tools user base grows (possibly within the existing projects).
Starting with a single web application server with a host name of webapp027.NAservers.ibm.com, we add four aliases to that server name in the DNS:
The Public URLs for these Jazz applications are set as follows:
Then six months later you bring on 50 more developers and 100 more testers as your projects ramp up. This necessitates moving the JTS and QM servers off of the existing server to provide additional server capacity. In order to accomplish this change, you are provided with two additional hardware servers: webapp028.NAservers.ibm.com and webapp029.NAservers.ibm.com. After installing and configuring the JTS application on webapp028 and QM application on webapp029, you change the DNS entries so that jts01.NAjazzservers.ibm.com is an alias for webapp028 and qm01.NAjazzservers.ibm.com is an alias for webapp029. The web applications are relocated but still point to the original databases containing the jazz repository data for their respective applications. This operation can be accomplished overnight without any hesitation as the actual repository was never touched during this process. After doing this distribution of the applications, the CCM and RM applications are still running on the original webapp027 server while JTS is running on webapp028 and QM on webapp029.
In summary, by using static logical host names as a component of the Public URL, you can safely and easily adjust your server topology based on your organizations changing needs. Hopefully, this strategy can be useful for your new Jazz product deployments.