It's all about the answers!

Ask a question

RTC versus Jira/SVN/CruiseControl

Roman Smirak (3164933) | asked Apr 24 '09, 4:49 a.m.
retagged Apr 04 '13, 10:37 p.m. by Nhi P Ta (18841018)
Some time ago I wrote this blog and posted it on my companys internal network. Im posting it here again in case others might find it helpful.
-Roman Smirak, Tieto

Recently Ive been asked at Tieto to compare Rational Team Concert (RTC) versus cheap or open-source alternative - an integration of Atlassians Jira, Subversion and one of popular building applications like CruiseControl, Maven or Hudson.

And the interest grows; on both sides: about RTC as well as the further. Therefore I decided to write a blog entry and it will be rather open and alive so further experiences and different opinions can be incorporated.

I used to use Bugzilla and CVS and Ant several years ago. And it was pretty good (especially when I have experienced software development without any versioning repository or defect tracker). Then we switched from Bugzilla + CVS to Jira and SVN and CruiseControl. And it was cool. Better usability, better integration, new features and extensibility. Cool.

We decided to pilot Jazz 1.5 year ago. And it is the next cool thing; I should rather say: mega-cool thing. When I saw Jazz for the first time (it was a demo recorded at EclipseCon 2007) I applauded: finally! This entry reflects my personal experience and opinion.

RTC disadvantages
Lets start with disadvantages first; it is shorter list and it is easier to get it finished early. And all of them are somehow doubtable so I would call them possible disadvantages.
As you guess, first and foremost, RTC 1.0 has been released recently, we cannot use it free of charge anymore and the license is pretty expensive (it is actually comparable with ClearCase license). Well, no surprise, it is IBM product, right. On the other hand, Jira is the commercial product as well and TCO (Total Cost of Ownership) is never $0 or less. You either pay time to get experienced, configure and maintain, HW/OS/DB cost, integration with other systems in use (is it even possible?), or you pay for a service of the original inventor. Although I cannot provide certain numbers you can consider a list of advantages below as return on investment of RTC.

Second possible disadvantage, all the tools mentioned (Jira, SVN, CruiseControl/Maven/Hudson) are pretty stable products and widely used; therefore it is rather easy to find people experienced with the tools. You can also find quite many plug-ins and other products based on Jira or CruiseControl (on the other hand, be careful: it is a general problem of the open-source one plug-in might be very stable and well supported by the community, other may lead to a disaster). As we have been using milestone builds (early adopters of not released yet functionality) we experienced defects to be reported back to RTC team. However, RTC has been already used by many pilots all over the world and the Jazz community is pretty active and strong. No surprise then that thanks to the iterative approach Jazz team released very mature, function rich and stable version 1.0 (how many products can say the same?) If you have any problem just go and visit a forum at and you get pretty quick and accurate help from the team itself (if you calculate US Europe time-difference) and yet again, how many (paid) support/warranty services can say the same?

RTC advantages
I will structure the chapter Advantages by feature. Although RTC includes many nice to have features I will focus on those I consider having rather crucial impact on our way of working; those I believe are worth considering.

Advantage #1: Agile planning and resource management
Jira is unofficially a successor of Bugzilla; it means a defect tracking is central concept there (Jira sees an abstract work entity as an issue good friend of mine recently asked: what is the social impact then if your team adopts a concept Everything is an issue? :-) The whole UI interface has been designed for a single developer/user submitting/fixing an issue. What if we are Agile? What if we have adopted collective planning practice (e.g. suggested by Scrum)? Lets assume we have a team of 7 developers having iteration planning meeting; to resolve/plan team tasks/defects/features they have to go developer by developer, task by tasks and resolve or (re-plan) it. No team view. No iteration. No notes in context. You have to create additional (separated from task DB!) Microsoft Word document or Wiki page to persist information like: What are the teams objectives? What are risks? How to evaluate we are done? What is our iteration test strategy?

Moreover, you dont get instant information about a quality of your planning: do we deliver on time or somebody is overloaded? Re-planning needed? Plus Jira doesnt include Resource management, i.e. you have to introduce additional tool: either Microsoft Project or Microsoft Excel (as I have seen in practice), however, yet again, you get scattered data sources and that causes pain and consumes additional time to get it all in sync. In fact, that is often source of problems: for example (as recently experienced), a team didnt include developers holiday and they noticed as the developer left the team: OK, nobody can simply absorb his tasks - we cannot finish on time.

RTC supports Agile planning by introducing a team view - actually Team first is the fundamental principle Jazz follows. I can get instant overall cross-team information. RTC includes resource management, i.e. every developer manages information about his/her availability: working week, holidays, time-zone. Thanks to that you can see on-line information about quality of your planning: who needs help due to heavy load and who can help him/her therefore the team can win and finish iteration on time.
Figure 1: RTC Iteration Plan

Iteration and Iteration plan is first class citizen in RTC. It has a starting date and an end date. Iterations can be grouped under a phase (we follow RUP approach). An overview page of the iteration plan contains all relevant information mentioned above: Objectives, Risks, Evaluation criteria, Follow-ups. You can add pages like Test plan, for instance. You dont need any separate Microsoft Word document.

RTC provides excellent usability; during your iteration planning you simply drag from your back-log (another Eclipse view) and drop it to the current plan. Even if you upgrade your Jira with GreenHopper plugin it is still far from RTC Eclipse UI based usability. Try it and calculate number of clicks. Try following scenarios with Jira: Super-task (collecting several sub-tasks) reassignment to another iteration/version; Resolving a task requires several clicks and web pages to be downloaded. I can guarantee you will use the scenarios on daily basis; on daily basis every millisecond of an overhead counts.

Advantage #2: Integrated SCM
As already mentioned, we used CVS several years ago - a simple but powerful concept. And we moved to Subversion (or SVN) later: better latency, better handling of binary files, lovely concept of a revision number (we stopped doing tags - we just stored revision number to each build we created magic!)

When we moved to Jazz one year ago I was confused; no operation as it used to be, no term like commit or update, new terms like deliver and so on. Stop. New terminology or actions shouldn't be any showstopper - that would be silly; that is called the progress, isn't it?

Therefore I started thinking (wow!); and I realized the new power: A concept of change-sets, flows, my workspace at a repository side, private build and the integration.

Let me explain the benefit by comparing with common story with SVN/CVS where you commit as soon as you think your code is "cooked" enough to be checked in the repository. And you might run your build to get it continuously integrated, right. And you might get surprised by failure of the build since you have forgotten to integrate the latest change of your colleague or you have simply forgotten to comment your changes or ... There are myriads of reasons why you need to make a small fix and check in again... Run the build and... Ups, it has failed again. You don't even write a revision comment anymore. But it is very painful later as you need to merge or roll-back the changes.

Typical scenarios, you name it.

Jazz creates your private area in the repository (you might say a branch in terms of SVN) by default (it's not a local workspace - it's on the server) - there you get you change checked in immediately (you can turn off the feature) and you can ask Jazz to create your private build from it without messing up the upper stream which means the team integration stream. Have you noticed? You need integration with building engine to enable the feature. All the simple changes are collected in a single change-set automatically associated with your task (or work item in general). Your colleagues review/approve the changes, or simply comment or ask the questions (automatically associated with the task - change-set): you develop your code in the context.
Figure 2a: Associating a Change-set with the task
Figure 2b: Change-set associated with the task

What is the result? As you run your private build successfully (which means the whole product integrated, all unit tests passed, all rules successfully applied) you might be sure you don't break the build and you avoid several stupid check-ins in the repository making roll-backs or merging really painful later. As you get instant info about changes made by your team mates in the repository (Jazz shows a popup message informing about new delivered change-set in the repository) you get integrated with latest changes - and yet again, you avoid future conflicts and you won't mess up the repository.

You might say: we have integrated Jira and SVN as well. Ok, but you should see the Eclipse based UI - recently I joined my friend who was still working with Jira and it was very painful to watch: many clicks, ugly interface. Moreover, to make the integration story happen you need to either use tools like Mylyn or convince each and every developer to put Jira issue id in every revision comment. And it is painful and not maintainable.

So, as your code becomes mature, integrated and well tested, you can deliver it into your team stream - ie. the changes become visible to your team mates. Beside the mentioned fact that you get consistent and error resistant changes (fewer changes) in your repository, you also get final delta associated with your task: in case of Jira-SVN integration you get several commits associated with your task and you have to compile all of them to get the complete view what has happened. And that is not only hard to do, that's impossible. You need a tool to do that. Jazz provides the complete view. And all the deltas you need.

You deliver the changes to your team's integration stream (an upper stream) - and as soon as your team gets stable, integrated and well tested state of the stream, you simply repeat same story again and you deliver it one stream up. Simple. Powerful.

Moreover, you can set the rule that nobody can deliver before he gets an approval from a leader. And that's another strong area of Jazz. Oh man, there are so many things... (Read more here).

Advantage #3: Integrated and centralized building
As I've mentioned, we used CruiseControl for quite long time. Actually, we leveraged wiki to store build parameters like label, status (built, verified, customer accepted, released, etc.) a customer id who migrated to the release and so on. Of course, you manage the info manually and it introduces errors (especially in hectic period right before a release). Later, when customer calls and reports a bug, you think this local workspace might be the right one so you switch your Eclipse (you've been developing new stuff) to the workspace and you get plenty of compilation errors so you delete the workspace and as soon as you figure out the right revision you check it out to your machine; then you ask yourself: what was the version of a library X and it's 1 hour later and you haven't still reconstructed the workspace therefore you decide to hang up and use the latest workspace; but you can't reproduce the error, oh my...

Jazz collects all the information related to a build automatically (ie. changes and work items included, tests passed/failed, etc.); as your customer calls and reports a defect you can restore the workspace by one click to trace the bug.
Figure 3: Build Result

You can tag a build and search it easily later.

Your testers can report a defect against the build by one click - it will be automatically associated.

21st century UI.

Little by little and you save huge amount of time in the end of a day.

Besides nice and friendly interface it's worth mentioning the architecture: Jazz separates a server (control point) and a build engine (running a build process). What it means: if you have been developing legacy (mix of technologies like C, C++, VisualBasic, Java, Flash, etc.) code and you decide to adopt continuous integration then you know the challenge very well: you must build different pieces on different platforms and it takes ages to compile.

You can register several build engines in Jazz; each build engine can run on different platform or machine and might compile different piece of your application in parallel. Sounds good, doesn't it?

We run one build engine on Windows since we need to use win native application; our second build engine runs on Linux. At the same time we start and check out new builds from single point: from developer's Eclipse. (Read more here).

Advantage #4: Open standard integration platform
You still think: Nice but I'm fine with my integration of Jira-SVN-CruiseControl or whatever... Maybe it's not so nice and lovely but it works.

My answer would be: the devil is in the detail. Try it out and you will experience the difference. Jazz actually integrates all the features by design or intentionally; it's not any post mortem intent to put all the pieces together - the approach must face certain constraints sooner or later.

Moreover, it makes it easier to setup new environment for a newcomer: you need to prepare a guideline or downloadable all-in-one package; but in hectic times (it means usually) it's difficult to keep it up-to-date; the guy needs to download and install Eclipse + all the plug-ins + all the libraries. He needs to know the repository address; to store all URL as bookmarks.

New guy joined us recently; I just added him into repository, Jazz generated a welcome email automatically; as soon as he downloaded a client he was ready to connect - and he got all the stuff available immediately: workspace, iteration plans, builds, reports; few clicks away.

Moreover, Jazz introduced an open standard called Open Collaboration Lifecycle other vendors are about to join. Nowadays it provides integration with SVN, CleareCase, Microsoft Sharepoint. And other will come. If you are CTO and the integration or data collection cross various sources is your theme, Jazz means an option how to stay free. You don't get dependent on one technology or vendor.

I believe it is vital to enable diversity; at the same time we are in a situation when it's difficult to start a new project in Ostrava since you need to deploy same tools (environment) as the other teams; they cannot use tools they are familiar with and they cannot leverage licenses. And it takes time to get it all in place.

Or as a line/department manager you can't ever collect any metrics automatically cross projects in your line/department since it's completely different environment behind each doors.

These days we start a pilot: we would like to demonstrate the integration capabilities of Jazz (e.g. integration with Jira) and collection of measures cross different sources.

Advantage #5: various resources and great support
Despite the fact that Jazz or Rational Team Concert is brand new product you can find great materials to learn about it; to name few:

-Roman Smirak, Tieto=

25 answers

permanent link
Jens Melgaard (4614) | answered Feb 15 '10, 9:16 a.m.
Also I think there is some very unfair parts, or things you list them as advantages where they are really just done differently.
- #1: Atlassian does provide a Agile planning add-on for Jira (GreenHopper)
- #2: The integrated SCM is better or worse depending on preferences.
- #2: Tightly integrated tool can bee an obstruction for tailoring processes (Something that is IBM's biggest problem)
- #2: The IDE integration is as misunderstood and failed by both Atlassian and IBM as it can be IMO.
- #3: Atlassian has there Bamboo for CI.
- #4: Jira also integrates with alot of outside products as well as supplying a API for developing new add-on.
- #5: Jira, SVN, CC and more also have great communities.

What im trying to say is that this comparison seems at all levels Unfiar to Atlassian since you choose a partially integrated solution vs. a fully integrated solution. to get a fully integrated solution by Atlassian look at all of:
- Jira (Issue tracking)
- Confluence (Wiki)
- GreenHopper (Agile Project management)
- Bamboo (Continues Integration Server)
- Crusible (if you do something as silly as Code reviews to lift quality)
- FishEye (for reviews, repository info, and issue linking)
- Crowd (for single sign on, integrate with LDAP if possible)

For SCC maybe look at both SVN and Perforce.


All that said, RTC does seem to be a much better direction than its predecessor (CC/CQ)...
I'm not convinced that it is as shiny as you put forth, not in the least since I have seen it demonstrated first hand, and it does have it's shortcomings as anything else.

Nor am I convinced that it is better than a Integrated Atlassian solution, just different in terms that it has some minor advantages, some major ones, but it has disadvantages as well, and more than you mention.

permanent link
Seth Packham (1.4k32213) | answered Apr 24 '09, 10:20 a.m.
Thanks for posting this, Roman! I've marked the topic as a "sticky" so it will stay at the top of the forum for the time being. Great stuff.

permanent link
Ken Creager (6542220) | answered Jun 05 '09, 12:44 p.m.
Hey, can anyone else comment, and/or update with RTC 2.0??

permanent link
Duane Thomas (6) | answered Jul 27 '09, 4:48 p.m.
I'm also interested in similar comparisons to RTC 2.0.


permanent link
Cali LaFollett (1111) | answered Aug 05 '09, 9:30 a.m.
Hey, can anyone else comment, and/or update with RTC 2.0??

Only a little. We were finally able to get the 2.0 release installed in our corporate environment on Monday. I'm not familiar with all the new features but can comment on performance.

The speed at which RTC now operates feels to be at least 3 times faster. Most all operations that previously had delays associated with them now are very fast with many being near instantanious. Great job by the RTC team to accomplish this feat AND add all the new goodies!!!

permanent link
Kevin Crocker (20185) | answered Aug 11 '09, 1:35 p.m.
Some time ago I wrote this blog and posted it on my companys internal network. Im posting it here again in case others might find it helpful.
-Roman Smirak, Tieto

Roman, great post. I've just been added to a live project where we are going to be doing almost the exact thing:

Starting point - hardware with an OS (CentOS)

I'm going to be getting everything else sorted out and up and running (JTS 1, RTC 2, ...) - so, any helpful pointers would sure be welcome.


permanent link
Kevin Crocker (20185) | answered Aug 12 '09, 3:41 p.m.
Some time ago I wrote this blog and posted it on my companys internal network. Im posting it here again in case others might find it helpful.
-Roman Smirak, Tieto

Roman, great post. I've just been added to a live project where we are going to be doing almost the exact thing:

Starting point - hardware with an OS (CentOS)

I'm going to be getting everything else sorted out and up and running (JTS 1, RTC 2, ...) - so, any helpful pointers would sure be welcome.


update - the decision has been made to move to Red Hat

permanent link
Suresh Krishna (6652) | answered Jun 18 '10, 2:02 p.m.
Generally, i agree with most of the points. For sure, RTC provides a out of the box solutions for many enterprises. I worked with Automotive giant in Germany where we tried to consolidate different tools and the process into a single platform.

In 2006, we did it with set of tools like Eclipse, JIRA and CVS for the development environment. Of course, RTC provides much more functionality and cohesiveness.

Irrespective of team size, i would definitely gravitate towards the RTC for the Software development and Process management.

permanent link
Seema Gairola (611) | answered Jun 23 '10, 10:27 p.m.
Getting following error when trying to setup Project in RTC


CRJAZ0106I The request for URL "/jazz/service/" was denied with a Not Available status.

Please let me know how to rectify it.

Thanks & Regards

permanent link
Andrew Ukasick (6) | answered Aug 03 '10, 4:04 p.m.
I agree with melgaard completely and I would add two more VERY important points of comparison.

1) Support for geographically dispersed development. The integrated SCM in RTC seems to follow a clearcase model and we all know how terrible clearcase is across a WAN. SVN on the other hand performs beautifully for a global audience even from a single central server.
2) Cost. We can deploy Subverion integrated with JIRA & GreenHopper (for Agile) and host both from a single 2 node Linux cluster very effectively to support 10,000+ globally distributed users (doing it now) for a total license cost of $12,000 up front and $6,0000 per year license renewals. That's an annual software license cost of $1.20 per user year one and 60 cents per user annually thereafter. Compare that to the cost of RTC?

Ralph Schoon commented Apr 05 '13, 7:38 a.m. | edited Apr 05 '13, 7:39 a.m.

Even if that answer is 3 years old, I think this should be commented.

Support for geographically dispersed development. The integrated SCM in RTC seems to follow a clearcase model and we all know how terrible clearcase is across a WAN. SVN on the other hand performs beautifully for a global audience even from a single central server.
This is mixing up concepts and technology and is just maybe a misconception because of a lack of technical information.
The concept in Clear Case is still very good. Why ClearCase has issues across the WAN in because the underlying communication technology is based on remote procedure calls. It was very advanced when invented - a time where WAN was probably a vision of few people. In the decades after that other technologies like HTTP came up and made WAN possible and ClearCase WAN performance suffers from architectural decisions made back when there where few other choices.
RTC uses a lot of the advanced concepts of clear case and has much better WAN performance.

Your answer

Register or to post your answer.