What are the risks when using Rational Team Concert?

Question

What are the risks associated with using Rational Team Concert in software development?

Answer 1

I know that this is a kind of old stream, but if others came here, I shared my personal experience.

We have used it in recent years here, and since the RTC headliner has turned into SCM, I simply do not trust my files.

The workflows are so varied that other SCMs as a whole are a complex and complex system that from time to time makes you lose your changes.

The fact that there is an article on the proposed function called “Backup” only says that I’m not mistaken, the fact that there is a need for such a function tells the story of how changes can suddenly disappear. - https://jazz.net/library/article/191/?errno=1

Of the other SCMs, we are pretty much used to the fact that only a “revert” overwrites local changes. In RTC, this happens in many other cases. One must ask how difficult it can be to merge files and / or conflict in these situations? ...

RTC Will overwrite files if you:

• Re-synchronize the workspace, and since you cannot check it due to WS synchronization, you cannot avoid it, so by God, make a backup before you do it!
• Accepting changes, despite the fact that everyone else does SCM ... He will offer you to check local changes before accepting the changes, but do not forget to click "yes" on PRAY that he has detected all local changes.
• Random? ... I'm sure I experienced other cases where the changes disappeared, but only the 2 above were the things that I could apply with my finger ...
• Return ... Obviously, the only bullet that really should be on this list.

It may be “design” ... But then I would like to vote for a really bad design.

Also, as indicated in another case, if you are in Visual Studio, ALWAYS click to update remote and local changes before checking. A solution as subversive activity (as it was before) detects changes much better than RTC, and thus w20> ...

In addition, both SVN and Git also have large implementations in many IDEs ... I think it took some time until Git became acceptable for use in Visual Studio, but now for sure! Although there are still features to be desired. SVN can be integrated with many work-item / issue tracking systems, and for Jira integration, I just prefer to write problem numbers in the comments, it's faster and easier ... And it creates a link because FishEye collects change sets, so Jira will display messages about the problems.

I can not say how Git / Stash combo or SVN vs. YouTrack / Mingle. But in RTC, the workflow of linking work items to commit becomes a huge overhead, so we stopped using it = useless function.

Then there is all the planning, work item, scrum, etc. part of the system ... The only part I will ever love is the laughter that he gives me from time to time. Other than that, it's close to useless ... Go to Jira + GreenHopper, Mingle, YouTrack instead ...

One of the fun things is that IBM is trying to sell it on Integration and how much you save on it ... Since these solutions are so widespread, there are tons of good solutions where you can literally install it should not touch your finger. until you decide it's time to upgrade to a newer version of this software. Also, the “estimated time savings for administrators” just goes ten times so they can run around and help sort out the many issues that the RTC seems to have brought.

Therefore, I would advise RTC. And Github, Codeplex, Bitbucket, etc. More than proven that things like Git, SVN, etc. Really scaled ...

Answer 2

We use RTC in the office, and it works quite well. Although you need to know two things:

• This is actually not a distributed version control system like Git or Mercurial. It is more like CVS. However, it does support change sets.
• Do not use it in a derby database. In our situation, he crashed many times. Now we run it on DB / 2, and now it works stably.
• It also supports the full application life cycle, but for me it's more of a burden of a bloated system than a great thing.
• This is a great system if you come from CVS or Subversion.
• This is nothing special if you came from Git or Mercurial.

Answer 3

I participate in a small team that uses the Rational Team Concert (RTC, first version 2 and now version 3) every day for Visual Studio 2010 for about 9 months.

I agree with Benjamin's comments on blocking the provider. "Lack of understanding or training" for us manifested itself many times.

I highly recommend using RTC for version control in Visual Studio , and any Visual Studio user who has the freedom to choose their source control tool should be able to find a suitable alternative without much effort. The / etc work item tracking element (a non-source component) is good, but here are some considerations regarding its integration with w / VS2010 source control.

We learned that the RTC “Pending Changes” panel is not trustworthy on its surface - we must constantly (and manually) “update” the panel to find out what differences exist between our workstations and the repository. It is not uncommon that we share our work with the team only to find out that some files were not sent to the repository (which led to a broken assembly for teammates), despite the fact that the Pending Changes panel tells us that no changes were pending after we “delivered” (the RTC term for “registration”) for the team.

Even worse, this Pending Change confusion caused our team to completely lose code several times. To whatever extent our ignorance or oversight caused these losses, we did not experience them with alternative source control products. He believes that the RTC client believes that we do not have any “pending changes” when we accept the work of others (accepting another developer modification in the file you changed may overwrite your changes if RTC does not understand what you changed file).

The Show History and Compare with Previous Repositories clients suggest intermittently disabling themselves in our context menus. At these points, manual workarounds needed to view (or annotate) the history of file changes are time consuming at best.

If we have too many files changed on our workstation at any given time, the Pending Changes panel stops showing us the list of files - instead, an account is displayed. The number of simultaneously modified files necessary for this is hundreds (which, admittedly, is a large number), and therefore it is rather rare to see this, but it is not surprising for large refactorings in large code bases to affect this many files.

These are defects for only one panel. Other behaviors associated with client source-control suggestions are also bugs / non-intuitive.

As a rule, the RTC2 VS2010 client (most of my usage time) offered a level of quality that I associate with the beta product. The RTC3 VS2010 client (from which I made all of the above remarks) is better and brings new features (for example, the ability to set the current work item), but I would not recommend it to any Visual Studio user with parameters that select the source control product. He remains more suspicious and constantly suspect.

Answer 4

Rational team concert? Risks: blocking a provider that is not suitable for your purpose does not match your workflows, misunderstandings, or training.

Real time clock? lack of accuracy for your application

Real-time control? Guaranteed Delay. Especially in OSs that do not provide anything specific. In addition, RTC applications are very multi-threading and require programmers who take a very strategic approach to concurrency management to achieve real-time control

Answer 5

Block Concert Team? It is doubtful. You can always export your entire SCM repository to Subversion out of the box. All work items can be exported via CSV files ... Or you could use the provided Java SDK to export everything ... I think they made it as little lock as possible.

Answer 6

I am part of the development team that developed the RTC client for Visual Studio, and I am disappointed that your experience with the RTC VS client was not satisfactory. I came back and looked at the defects that you registered on jazz.net - we seem to have solved most of them, and those who remain do not talk about the reliability of viewing pending changes or about menu items that are inexplicably disabled.

We did not have similar complaints from other users, so I ask you to register defects in relation to the problems that you described in this message with the trace files. I believe in some of the shortcomings that you said that they cannot be reproduced - if you are still experiencing them, repeat these defects.

Greetings --Rupa

Answer 7

Reporting is weak. The data that you need is there, but it’s difficult to get it into the format that the client will accept. I need a ProPath compliant requirement traceability matrix and its close relative, the confirmation cross-reference matrix (VCRM). Good luck with that.

This is not an open source. You do not have a community of users viewing the source to identify and fix vulnerabilities. This is why the Pentagon (the US military) is becoming increasingly susceptible to open source; It's hard to touch the Trojan horse into the code everyone is looking at.

What is not a risk is that you will eventually be able to do your job. Nobody resigned for an IBM gathering. :-)

Answer 8

To answer the original question, my team and I have been using VS Client for RTC since our first milestone about 3 and a half years ago, and now we have a large user base, so I would recommend posting this question to https: // jazz. net / forums / viewforum.php? f = 17 .

To answer your questions:

• No vendor locks. I would say that we have a truly open history compared to many other tools in the change and configuration management domain.
• RTC has a good history of integration with Visual Studio. It is completely native, built around VS packages and integrates well with VS VS explorer, properties, tools, error presentation, editor environment, etc., giving a natural look to VS users.
• There are tons of blogs, articles, videos, and forum posts on jazz.net. You can take a look at them to feel the integration.
• You can also create a sandbox on jazz.net and connect to it using the RTC VS client client to find out the experience for yourself.

Greetings

- Rup

Answer 9

Risks in not using Rational Team Concert:

• Using tools that do not integrate well with each other. RTC has integrated planning, bug tracking, source management, assembly, and reporting. This way, you can easily see which fixes were included in a particular assembly, which code was changed, and why. You can comment on the work item when you don’t like the correction in the code, take a screenshot to illustrate the point.
• Use tools that do not grow with your project. You can quickly get started with RTC using a predefined process template. When you add more members, more teams, more code, you can set up the rules of the process to decide who should check for errors, tighten the rules until the end of the release, automate the assembly, and configure phased flows. etc. RTC is used by small teams and huge teams.
• Using tools that work only for developers or managers, but not for both. With RTC, managers get the opportunity to create fancy dashboards to track project status in the web interface. Developers can work in the IDE on Windows, Linux, Mac (Eclipse, VS on Windows). There is also a command line tool. And yet, their 4.0 Beta has a new Windows Explorer client. Because the IDE is cool for a developer, but not so cool for a tester or graphic designer.
• Using tools that block you in a particular OS. As stated in 3. Perhaps today your project is mainly Windows, but what about tomorrow? RTC has clients for Windows, Linux, and Mac.

But just as I went to the Apple store to try the latest gadget, you can go to www.jazz.net and download the trial version of RTC to see for yourself. Import some data into it and see how it feels for you and your team.