It's all about the answers!

Ask a question

RTC 6.0.2 or Git as SCM / RTC for defect tracking mandatory


Ilona Krammer (159549) | asked Nov 23 '16, 6:37 a.m.
My company has decided to use RTC for defect tracking and planning and some of my colleagues want to use Git as a source code management system instead of RTC (and they basically would like to have it for the whole company).

What are the pros and cons of using Git instead of RTC?

I mean, from an integration point of view RTC wins big time with easy work item connection and build definitions including build result display etc.

I'm finding a lot about Git and/or RTC but it's not always recent so I'm not sure how much I can trust that information. We are using RTC 6.0.2 and are probably going to use the current Gitlab server.

2 answers



permanent link
Rolf Nelson (617159) | answered Nov 23 '16, 10:25 a.m.
JAZZ DEVELOPER
There are a number of differences. RTC does integrate with Git, GitLab and GitHub and our strategy is to support integration with any Git.  However, there are a number of differences some which you mentioned.  There is a fairly detailed slide deck here that discuss the RTC integration with the various Git variants and how it works.  See:

http://www.slideshare.net/ibm/ibm-rational-team-concert-integration-with-git-source-control

One can associate git commits to RTC work items, but there is not a nice UI that presents to the user for example a pick list of work items to associate.  You can;t set the context to work item A and then commit away in Git and have the association be automated.  You also don't have process pre-condition support for GitHub operations so if you are trying to enforce work item associations you may not be able to in some Git variants that do not provide a pre-commit hook for us to enforce pre-conditions.  Some features, are not available to Git users, for example, support for Global Configurations is not enabled and support for reporting (which is new in 6.0.3 - soon to be released) is not available in Git.  The biggest difference is that RTC SCM is centralized and Git variants are de-centralized.  So although developer performance is faster as the entire repository is local to the developer, this means in a larger enterprise you will likely have many repertories to manage and trying to say eradicate a bad method in all instances where that method may have been used will be harder to find across a myriad of repositories.  Also, if your users use GitHub, they will also have access to GitHub issues, which is a basic issue tracking system, with limited customization.  So if you unleash the freedom for developers to choose to use GitHub you may want to mange their use of RTC work items instead of GitHub issues for reporting on project status.  This way you can use RTC or CLM as the backbone for tracking, reporting, and planning  (or formal Requirements Management or Test Management) and CLM while allowing teams to use Git. What we see are two different markets and in very large organizations where RTC is being used they may need to manage pockets of Git for Android device development or for Apple xCode mobile app development.  But they leverage RTC/CLM across all their development teams to report and manage lifecycle traceability across all their projects.  This applies to SAFe or agile development as well. You can roll out SAFe and have some teams use RTC SCM and select teams use Git if it is a better fit and still manage project status and planning in a managed way.  I'll probably try to write a blog on this as it comes up a lot.  It's not a simple decision and it involves more than just developers, but gets to how you manage software development in a regulated environment, vs. how you manage software development in a two pizza independent software development project.

permanent link
Benny Simonsen (1311) | answered Nov 23 '16, 9:48 a.m.
With respect to speed and stability Git wins.
Speed: > 1000 times difference
Stability: Inf (git is stable, RTC scm is buggy)

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.