RTC versus Jira/SVN/CruiseControl
Roman Smirak (316●49●33)
| asked Apr 24 '09, 4:49 a.m.
retagged Apr 04 '13, 10:37 p.m. by Nhi P Ta (188●4●10●18) -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. 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: 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 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 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... 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
First off, for full disclosure, I am an IBM/Rational employee. I have to say that I don't mind people calling other views unbalanced. However this particular post seems even more unbalanced in the opposite direction. You're spewing some misinformation here.
Geographically distributed (or dispersed) development is the EXPECTED situation for us when we deploy RTC. It has nothing to do with ClearCase, and the mechanism is completely different. Speed tests are easy to manipulate, so trotting out a white paper on speed is really misdirection. It's probably more appropriate for people to see what the performance is on their particular infrastructure, with their own particular hardware, network and security issues. Cost is always an interesting topic. While licensing costs are more for RTC, there total cost of ownership has many more factors than that. In general, I am not religiously opposed to Subversion/JIRA/Greenhopper combination, because I have heard people tell me that it will work for small teams, and I will take them at their word. What I do notice is that many of my larger customers consider this combination to be too much of a risk, in terms of available support, scalability, ability to integrate with other tools, etc. I wrote a blog article on a comparison of Jazz and open source (http://dtoczala.wordpress.com/2009/02/18/how-does-rational-jazz-compare-with-open-source-solutions/) over a year ago in February of 2009. Many of the concepts still hold true, although some of the information is a bit dated (Jazz supports far more than the original 250 user limit mentioned in the blog posting). I would encourage people to get the most up to date information, and then decide which solution best fits their current tactical and strategic situation. |
The author suggests that a similarity in the conceptual model between ClearCase and RTC implies a similar architecture and implementation. That is not true in the case of RTC. The "old" ClearCase client was designed as client/server architecture with many round trips for usage in a LAN. RTC has a service/resource oriented architecture and is largely implemented using http. It is designed for usage across an Intranet. This is evidenced by experinece at IBM and at many customer sites using RTC in geographically dispersed teams. Lothar Kappen, IBM Rational |
|
|
Hi, overall I disagree with this biased statement!
As I closely monitor ALM tools formerly known as CSD collaborative software development tools for more then 9 years now, I can only say that I'm too tired to read through vendor sponsered ratings. Please try to post unbiased statements that help users and try to avoid statements like the one from Dan Toczala. I read his article about "Cost of Ownership" and it is so highly contrived that it hurts. If this is IBM Rationals approach to convince customers I would prefer that you beef up your RTC Sandbox as it seems to be quite slow, buggy and counterintuitive. It started with the initial login which failed, followed by a deadlink posted by the IBM support. Same to the downloaded RTC version which ended up with a deadlock due to insufficient permissions for the admin role ?! And please don't tell me that this product requires IBM consultants to setup as I know how well IBM's competitors do. If Jazz is all about "Innovate" then please do that on the technical level and not on the marketing/lobbying level! And the Jazz repository seems to me like an incarnation of VisualAge Envy and that expierence is something we don't miss. If Jazz is so good then I expect that the repository can seemlessly be replaced with Git, Bazar, Subversion, Mercurial, Perforce et al e.g. via OSLC. I would recommend IBM to opensource Jazz and sell premium services/features atop of it. That was one of the Eclipse success factors. |
Great Post Roman - I hope you do not mind but I have included some of the content on my blog and will point people to you as well. I found this extrmely helpful - keep up the great posts!
|
|
|
|
|
Generally, i agree with most of the points. Yes, seems the most sensible way to go :) |
That is actually a good point to discuss, the "innovativeness". As 2 - 3 month experience user of Jazz, i can say that my expectations for such kind of product were much lower. Previously i had used ClearCase, so the JAZZ replacement is more like a fairy tale. Jazz works a thousand times faster than ClearCase, and can be comparable to modern DCVS in terms of speed (i.e. it won't fall off the graph). The work items are really really good. For example, one nice feature is that if you write "action <some number" then this will get underlined and made as hyperlinke to the action. The same goes for attachments and other links. That is really great. So basically thumbs up for good product as to what could be expected from corporation. However, the downsides are: a) It craches alot. I don't care if it is whole Java VM which crash, or just RSA, or Jazz, it crashes and makes me wait. b) Does it have a command line tool to work with source control? So far i have not figured out how to checkout a second or third or tenth copy of my code, since everything is tightly integrated into Eclipse. While marketing persons will put that as a tremendous huge nice feature, i treat it differently in different context. Yes, integration is good, but i can NOT write simply git/hg/bzr clone urlToMyRepo pathToLocalDisk The some goes for commit, push c) Merging code is still a problem. It is just non-intuitive, and we keep overriding each other code. I will do point out that with SVN that happened to me also time to time. But with hg (working with that for more than a year now) that does not occur at all. However, with Jazz that is a problem. still. and i do not expect to improve it here, since when i posted my finding in the forum, i got a standard reply, which can be summarised to basically "we have a corporate product, everybody is paying lots of money for it, so be happy". d) Pulling code is strange. For example, if i have non commited changes, and i want to pull and update, i get presented with this combobox: "Unchecked-in changes" "You have unchecked-in changes that might be overwritten or may result in errors when you accept. Do you want to check-in the changes before running accept?" NO, i do not want to commit, i have not yet finished. Why do you say that "may result in errors when you accept"?? Does it mean that Jazz can not normally merge changes? No, it can not, and it asks me to think alot and plan ahead. This should be fixed, that's simply not a feature :) So to summarise, despite all the criticism, Jazz is a good platform. It does have issues with code versioning, and maybe some other issues, but it is a viable option. If i would get to chose whether we would choose Jazz. I would chose Jazz for planning and tickets, but would choose other DCVS system for source control. That is my personal opinion. You have all rights to disagree with it. |
|
All very good points, some of them I won't argue, and some of them I can actually help you with.
Starting with the stuff that I will not argue, I can't argue crashes, if they are happening to you then they are real. I run on Linux, and have never had a crash, but that doesn't help you any (grin). 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) 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). The thing that drives most of the misunderstanding here is the way RTC really works. With other repositories, once you check something in, it is committed to the shared repository, and the rest of the development team then sees your changes. RTC doesn't really do that, and our terminology can be confusing to people that are used to this type of SCM process. 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? |
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.