Blogs about Jazz

Blogs > Jazz Team Blog >

The Rational Team Concert SCM Strategy

Now that Rational Team Concert (RTC) integrates with Git as an alternative source control provider, we sometimes get asked about our source control management (SCM) strategy. Why Git? Does that mean we’re not going to invest in RTC’s built-in SCM long term? How do they play together?

This blog is intended to dispel any such concerns you may have and to clarify the role of Git in the Rational Team Concert SCM story.

Our background with Git

In the RTC 5.x timeframe, some of our customers indicated that there were pockets of Git usage in their companies – and they wanted to know if there was a way we could handle Git as an alternative SCM in RTC. Through follow-up discussions we learned that the use of multiple SCM systems, especially a combination of RTC SCM and Git, was becoming a reality in many companies.

Small teams and startup initiatives were interested in Git and wanted to try it out for their projects. Some teams needed to consume or contribute to open source libraries that were hosted in Git repositories. Some thought Git was cool. Others liked the fact that it was free or inexpensive.

At the same time, most of these customers – especially those in regulated industries –  continued to have sophisticated SCM use cases that only an enterprise-grade SCM system can offer. They couldn’t tolerate data spills commonly associated with a distributed version control system, had stringent requirements for governance and auditability, needed cross domain traceability, or simply required fine-grained control.

These customers could have continued to use Git as the SCM system in pockets, and RTC for tracking and planning in all teams, but what they were really looking for was a seamless integration. They wanted common users and roles, Git specific process control and permissions, teams using either RTC-SCM or Git or sometimes both, and working with a common plan and common backlog.

Our strategy going forward

After brainstorming these use cases, the RTC team concluded that we wouldn’t host Git or have our own implementation of Git. Rather than release features across multiple SCMs, our strength would be our flexibility and versatility    allowing users to choose their own SCM, while at the same time bringing the power of RTC to the Git work flow in terms of common process management, tracking and planning, reports and so on.

We will continue to focus on our own built-in SCM and to release the features and functions that our customers want, but at the same time, cater to the Git teams by making the integration as useful and as flexible as we can.

So, with this strategy in mind, we’ve continued to invest heavily in our built-in SCM, and just over the last couple of years, we’ve delivered a number of advanced SCM features –  better merge support, rolling back changes, our own code review tool, a team process around check-ins, linking files to versioned artifacts, improved reporting around change sets, major improvements to our Windows Shell integration – to name a few in a long list. At the same time, we’ve also enhanced our integration with Git – improved process support, better work item management and linking, and closer integration with GitHub and GitLab are just a few examples.

This is our strategy for the foreseeable future. For us, it’s never been a question of doing one at the cost of the other. RTC SCM is of course a much bigger investment, since it’s a fully featured SCM system that sits at the core of RTC. But we’re also very serious about continuing to improve our Git integration.

The feedback from customer focus groups tells us that so far, our strategy is working.

Sreerupa Sen
STSM, Technical Lead – Rational Team Concert