It's all about the answers!

Ask a question

RTC versus Jira/SVN/CruiseControl


4
1
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 http://jazz.net 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.

https://jazz.net/learn/content/docs/iteration-planning/bitmaps/plan_editor1.png
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.

https://jazz.net/learn/content/docs/source-control/advanced/images/20080604_07.png
Figure 2a: Associating a Change-set with the task

https://jazz.net/learn/content/docs/source-control/advanced/images/20080604_08.png
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.

https://jazz.net/learn/content/docs/client-tour/images/b2build37.png
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
Darius Damalakas (2632) | answered Feb 01 '11, 10:59 a.m.

Now to the things that I CAN help you with. There IS a command line for RTC, and you can do the things that you want to do. You can pull down code, check in changes, and deliver to the repository. Go and look here for the commands (http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0/index.jsp?topic=/com.ibm.team.scm.doc/topics/r_scm_cli_scm.html)


Thanks alot, i will have a look at it.



I think that merging and pulling code is easy, but that is a subjective thing. Check out this article on merging (http://jazz.net/library/article/39), and this one on stream strategies (http://jazz.net/library/article/599).


I have used ClearCase, Jazz, cvs, SourceSafe, MSTeam Foundation, subversion, Mercurial (hg), git and bazaar (bzr) source control systems. Some are centralized, some are decentralized, and some don't even have atomic commits.

From my point of view, merging is still something that can be learned from other projects, namely hg, git and bzr.




With RTC when you SAVE a file, your changes are stored on your local hard drive. Everyone is familiar with that. Now is where things get a bit different. When you CHECK IN a file, the changes are then stored in your repository workspace (NOT to be confused with the Eclipse workspace). This is your own little repository storage area kept up on the server. RTC tracks these changes, and can operate on these change sets, but they are not yet at a point where they are automatically shared with the rest of development team. At this point only you are seeing the changes that you checked in. So users will check in changes at a constant rate (as they make their changes) because it saves their changes, without imposing them on the remainder of the development team. Once you have a good set of changes, you will then DELIVER your change set(s), in an atomic operation, to the parent stream. This is the point where your team members will have visibility to your changes.

Now you can share changes in your repository workspace with individuals, but that is not done automatically. It is a manual operation where the other user will go and look for your change sets and apply them to their repository workspace. Since all workspaces are based off of the stream, once you DELIVER to the stream, those changes will show as incoming changes to the rest of the development team for their repository workspaces (kind of like a commit). The whole paradigm is a bit different than what you are used to.

Does this make sense or help you?

Well, thats something in between CVS and DCVS. The concept you explained is not difficult, or new. I would even say it is actually going mainstream during the last couple years.

So unfortunately no, it does not help me, but makes sense. However, it is the way Jazz works makes me unhappy, but the small stop-showers when merging the code. As i said, Jazz can not automatically merge non-conflicting changes, you have to manually press "auto-resolve" button, which is really weird decision. Maybe it has a meaning for that, but nonetheless i do not miss this button in other source control systems, and i would like it to be gone in jazz too.

Thanks for a great response! :)

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 02 '11, 11:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
For anyone interested in not having to press the "auto-resolve" button,
please add a comment to work item 148609 to indicate your
interest/support. I personally agree with this request (which is why I
posted the enhancement request :-), but it will need active support from
the RTC user community to be acted upon.

Cheers,
Geoff

On 2/1/2011 11:08 AM, dariusdamalakas wrote:

... Jazz can not automatically merge
non-conflicting changes, you have to manually press
"auto-resolve" button, which is really weird decision.
Maybe it has a meaning for that, but nonetheless i do not miss this
button in other source control systems, and i would like it to be
gone in jazz too.

permanent link
Jens Melgaard (4614) | answered Jul 11 '11, 4:59 a.m.
Ok, so now we have been using Rational Team Concert for like 6-9 month or so, and honestly that makes this post even worse...

What is my experience so far?... RTC seems to be more of a "Prototype" that an actual production ready product, I AM SORRY, but it is... The source control is the most bug free part of the software, and in 95% of the time it wont do more than annoy the user with an excessive amount of dialog where you might not really understand half of them.

The Planning and Task etc. part... That is even worse, but I guess that starting on implementing one client (Eclipse Client) and then suddenly changing minds and then putting all bets on another (Web Client) has left that in the state it is... Unfinished and with countless bugs and quirks... (MAKE Sure to select English as a language in your browser!... or it won't work)

The build server was scrapped on day one for us, it is simply to simple to provide anything we needed.

The task item to source tracking is very limited and only a fraction of what e.g. FishEye offers. All in all... With everything apart from the Source Control, My opinion is that Jira+GreenHopper+FishEye+Bamboo just works better and without all the horrible bugs!... And they have an excellent integration into several SCM's... Ohh and again it seems that the Maintenance is actually MORE expensive on RTC BECAUSE of all the bugs you suddenly need administrator help for...

The "Its the same platform so it just integrates" is all well, but what is the use when Jira, GreenHopper, Confluence, Bamboo, Svn (or make another SCM choice) kind of works out of the box... (unless you really have a non standard setup, but then your asking for trouble regardless of choosing RTC or the other)... The maintenance?... I have spent less than a day on that since I installed such a setup over 2 years ago... (Not a day as in 24 hours, but a day as a work day = 7.5 hours where i live).

I can't speak for e.g. ThoughtWorks suite or JetBrains suite for the same things, Im guessing they work better as well...

So SORRY.. this post is to positive and far from reality...

THAT SAID!... YOU ARE HEADING IN THE RIGHT DIRECTION!... and I wan't to emphasize on this...
- SCM: Million times better than your old attempt: ClearCase, and it even holds some interesting ideas over some of the competitors, I am not convinced that it is just better than "SVN, Plastic, Git, Mercurial, Perforce"... but at least it is now a competitor...
- Task management and planning: Kudos for choosing WEB as the platform to be, WHY ON EARTH you didn't do that from the beginning I have no IDEA... Most of the concepts are in place... now they just needs to get the "IT JUST WORKS" into them and you are missing a whole lot of usability...
- Task to code tracking: Way to weak to be useful for anything. But Get the other stuff fixed first after all, it is not the most important thing, it is a nice to have when you have it...
- Build server: I Would scrap your own and then make a better integration API... GO, Bamboo, Team City is all light years ahead of you... RTC will be an outdated platform before you catch up... SORRY!...
- CLI + API: Needs Documentation in a "Understandable" manner... Build automation outside the box is way to hard to do and to get help on...

I Already felt this was an Unfair comparison up front, NOW that I have actually used RTC for that long, I KNOW it is highly unfair... I would even claim that it is a straight up lie...

Sadly I can hardly prove it since I can't access the the numbers we have spent on RTC maintenance here. That is also why I emphasized on that RTC is on the right path.

permanent link
Fabien Araktingi (151317) | answered Apr 06 '12, 8:01 a.m.
Hi

I would be very interested if someone has some experiences by moving data from Jira to RTC.

I'm looking after the way to perform that.

Thanks for any feedback.

permanent link
JY Hsu (1111) | answered Mar 29 '13, 1:06 p.m.

Ok, so now we have been using Rational Team Concert for like 6-9 month or so, and honestly that makes this post even worse... 

What is my experience so far?... RTC seems to be more of a "Prototype" that an actual production ready product, I AM SORRY, but it is... The source control is the most bug free part of the software, and in 95% of the time it wont do more than annoy the user with an excessive amount of dialog where you might not really understand half of them. 

 Well, I am not sure what version of RTC you are using, but it seems like you are living in a parallel world compared with mine. I am using RTC 3.0 and I've never seen it crash. Not even once. I am using its eclipse plugin though, and I don't use Web UI too often because it's way better in eclipse. 

I don't do the build so I can't comment on the build server stuff. I don't know what FishEye provides, but the task to code tracking provided by RTC is pretty much enough for me. 

One thing that RTC is way ahead is the SCM part. Not that SVN or Git can't do the same thing that RTC can do, but it's much easier to do in RTC. The concept of RTC source control is a little complicated so you need to understand it. If you don't spend some time to understand it, it's very difficult to use. You will most likely see what you met: dialogs you don't understand, conflicts you can't resolve, overwriting other's changes. But once you understand how it works, it's actually quite powerful. It handles conflicts and merges pretty well. My team hasn't overwritten other's change for couple years. I like its ability to easily swap in and out multiple change sets without worrying that will mess up anything. I also like that it let you discard any parts of experimental codes that you made locally at will. So when you write part of codes and want to try something on top of your local change, you can do that. After the experiment is done, you can discard the experiment part but still keep your previous local changes. I understand this can be done with other SCM, but RTC let you do it with simple drag and drop.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.