使用Rational Team Concert有哪些風險？

Question

在軟件開發中使用Rational Team Concert會帶來什麼風險？

Answer 1

Rational Team Concert？風險是，供應商鎖定，不適合你的目的，不符合你的工作流程，缺乏理解或培訓

實時時鐘？您的應用缺乏準確性

實時控制？保證延遲。特別是在沒有提供任何特定功能的操作系統上。此外，RTC應用程序往往是高度線程化的，並且要求程序員採取非常具有策略性的方法來管理併發性以實現實時控制

Answer 2

Team Concert供應商鎖定？疑。您可以隨時將整個SCM存儲庫導出到Subversion。所有工作項目都可以通過CSV文件導出... 或者您可以使用提供的Java SDK導出所有內容...我認爲他們儘可能少地鎖定了內容。

Answer 3

我是一個小團隊的成員，他們每天都在使用Rational Team Concert（RTC;第一版本2，現在是第三版本），現在每天使用大約9個月。

我同意本傑明對供應商鎖定的評論。 「缺乏理解或培訓」的風險已經爲我們多次表現出來。

我強烈建議RTC不要在Visual Studio內使用RTC進行源代碼管理，任何有自由選擇源代碼控制工具的Visual Studio用戶都應該能夠在不費力的情況下找到合適的替代方案。工作項目跟蹤/等（非源代碼控制功能集）很好，但是這裏有一些關於它的源代碼控制集成w/VS2010的想法。我們必須不斷（手動）「刷新」窗格，以瞭解在我們的工作站和存儲庫之間存在什麼差異真的我們已經瞭解到RTC的「待定更改」窗格在其表面上不可信。我們與團隊共享我們的工作的情況並不少見，儘管「Pending Changes」窗格告訴我們沒有發送到存儲庫的一些文件是而不是（導致團隊成員損壞）。在我們向團隊「交付」（RTC的「簽入」期限）後，更改仍在進行中。

更糟糕的是，這種「待定變更」的混淆讓我們的團隊多次失去完整的代碼。無論在什麼程度上我們的無知或忽視都會導致這些損失，我們還沒有經歷過替代的源代碼管理產品。它認爲RTC客戶端認爲當我們接受他人的工作時，我們沒有任何「待定變更」（如果RTC沒有意識到您接受另一個開發者對您修改的文件的更改可以覆蓋您的更改已經改變了文件）。

客戶端的「顯示歷史記錄」和「與來自存儲庫的以前比較」產品會在我們的上下文菜單中間歇性地禁用它們自己。在這些時刻，查看（或註釋）文件修訂歷史記錄所需的手動解決方法至多是費力的。

如果我們在任何時候在我們的工作站上修改了太多文件，「Pending Changes」窗格會停止向我們顯示文件列表 - 它會顯示計數。實現此目的所需的同時修改文件的數量在數百個（這確實是一個很大的數目），所以我們很少看到這一點，但在大型代碼庫中進行大型重構來影響這些許多文件並不是聞所未聞。

這些只是一個窗格周圍的缺陷。圍繞客戶端的源代碼管理產品的其他行爲也是錯誤/不直觀的。

一般來說，RTC2 VS2010客戶端（我的大部分使用時間）提供的質量水平我用β產品相關聯。 RTC3的VS2010客戶端（我從這些客戶端獲得了上述所有觀察結果）更好，並且帶來了新功能（例如設置當前工作項目的功能），但我不會將它推薦給任何具有正在選擇的選項的Visual Studio用戶源代碼管理產品。它仍然越來越多，一直懷疑。

Answer 4

我就是開發RTC客戶端的Visual Studio開發團隊的一員，我很失望地得知，與RTC VS客戶端的體驗並不令人滿意。 我回過頭來看看你在jazz.net上登錄的缺陷 - 我們似乎已經解決了大部分缺陷，而那些仍然沒有談論Pending Changes視圖的可靠性或禁用莫名其妙的菜單項。

我們還沒有來自其他用戶的類似投訴，所以我想請您登錄缺陷對你已經在這個崗位描述，與跟蹤文件的問題。我相信你所說的一些缺陷是不能複製的 - 如果你還在經歷它們，請重新開啓這些缺陷。

乾杯 --Rupa

Answer 5

要回復到原來的問題，我和我的團隊一直在使用VS客戶端的RTC，因爲我們的第一個里程碑，年約3個半前，我們有一個龐大的用戶羣現在，我建議在https://jazz.net/forums/viewforum.php?f=17上發佈這個問題。

回答您的問題：

1. 沒有廠商鎖定插件。我想說，與變更和配置管理域中的其他許多工具相比，我們有一個非常開放的故事。
2. RTC與Visual Studio有良好的整合性。它完全是原生的，圍繞VS包構建，並與VS的解決方案資源管理器，屬性，工具，錯誤視圖，編輯器框架等很好地集成在一起，爲VS用戶提供本地外觀和感覺。
3. 在jazz.net上有大量的博客，文章，視頻和論壇帖子 - 你可以看看那些以獲得融合的感覺。
4. 您也可以在jazz.net上創建一個沙盒，並使用RTC VS Client連接到沙盒，爲自己找出體驗。

乾杯

--Rupa

Answer 6

使用Rational Team Concert在不的風險是

1. 使用不彼此很好地集成工具。 RTC集成了計劃，缺陷跟蹤，源代碼控制，構建和報告。所以你可以很容易地看到什麼修補程序進入了一個特定的版本，代碼被改變了，爲什麼。如果您不喜歡代碼中的修復，則可以對該工作項目發表評論，並通過截圖來說明一個觀點。
2. 使用不隨項目增長的工具。您可以使用預定義的流程模板快速開始使用RTC。隨着您添加更多成員，更多團隊和更多代碼，您可以調整流程規則，以決定誰應驗證錯誤，在發佈結束時收緊規則，自動構建，設置分階段流。 RTC由小型團隊和龐大的團隊使用。
3. 使用僅適用於開發人員或管理人員的工具，但不能同時工作。藉助RTC，管理人員可以構建花哨的儀表板來跟蹤Web UI中項目的健康狀況。開發人員可以在Windows，Linux，Mac（Eclipse，Windows上的VS）中的IDE中工作。還有一個命令行工具。而且更多的是，他們的4.0 Beta版以新的Windows資源管理器客戶端爲特色。因爲IDE對於開發人員來說很酷，但對於測試人員或圖形設計人員來說並不那麼酷。
4. 使用將您鎖定到特定操作系統的工具。如3所述，也許今天你的項目主要是Windows，但明天呢？ RTC擁有Windows，Linux和Mac的客戶端。

但就像我去蘋果商店試試最新的小工具，你可以去www.jazz.net並下載RTC的試用版來親自看看。將少量數據導入到數據中，並查看它對您和您的團隊的感受。

Answer 7

報告很薄弱。你所需要的數據在那裏，但是把它拿出來並轉換成客戶接受的格式是很難做到的。我需要一個ProPath兼容的需求追蹤矩陣和它的近親，一個驗證交叉參考矩陣（VCRM）。祝你好運。

它不是開源的。您沒有一個查看源代碼的用戶社區來識別和修復漏洞。後者是五角大樓（美國軍方）越來越接受開源的原因;很難將特洛伊木馬變成每個人都在看的代碼。

什麼不是風險是你最終能夠完成你的工作。沒有人因挑選IBM而被解僱。 :-)

Answer 8

我們在辦公室使用RTC，它工作得相當好。雖然你需要知道兩件事：

• 它並不是真正的分佈式版本控制系統，比如Git或Mercurial。它更像CVS。它確實支持更改集。
• 請勿將其與derby數據庫一起使用。它在我們的情況下無數次地墜毀。我們現在在DB/2上運行它，現在它運行穩定。
• 它也支持完整的應用程序生命週期，但對我來說，這是一個臃腫系統的負擔，而不是一件好事。
• 如果你來自CVS或Subversion，這是一個很棒的系統。
• 如果你來自Git或Mercurial，這沒什麼特別的。

Answer 9

我知道這是一個古老的線程，但如果其他人來這裏我分享我的個人經驗。

我們在過去幾年裏一直在使用它，並且作爲一個頭條新聞RTC已經發展成爲SCM，我根本不信任我的文件。

工作流程如此不同以至於其他供應鏈管理系統如此以至於整體而言，這是一個過於複雜和複雜的系統，不時會導致您失去更改。

事實上，有一篇關於所謂功能的文章，稱爲「備份棚」，只能說明我沒有錯的故事，需要這樣一個功能的事實告訴我們一個關於如何自我的故事變化可能突然消失。 - https://jazz.net/library/article/191/?errno=1

從其他供應鏈管理的我們非常習慣於只有「恢復」覆蓋本地更改。在RTC中，這發生在許多其他場合。一個得問問，怎麼努力也可能它是合併文件和/或在這些衝突的情況他們...

RTC將覆蓋文件，當您：

• 重新同步您的工作，因爲你無法從不同步的WS中檢入，你無法避免這種情況，所以在上帝的幫助下，先做好備份！
• yup這是正確的，儘管所有其他SCM的做法是......它會讓您在接受更改之前先檢查本地更改，但是請記住點擊「是」以致於PRAY它已經發現了所有本地更改。
• 隨機？...我相當肯定已經經歷過其他變化，其中變化消失了，但只有上述2已經是我已經能夠把手指...
• 恢復...顯然，只有一個子彈實際上應該在這個列表中。

這可能是「設計」......但後來我想投一個真的很糟糕的設計。

另外，除非另有說明，如果您使用的是Visual Studio，請始終在簽入前單擊刷新遠程和本地更改。作爲Subversion（儘可能老）的解決方案在發現更改時比RTC更好，因此GIT ...

此外，SVN和Git在許多IDE中都有很好的實現......我認爲花費一些時間直到Git變得可以忍受在Visual Studio中使用，但現在肯定是！雖然還有一些功能需要。 SVN可以與許多工作項目/問題跟蹤系統集成，但對於Jira集成，我實際上更喜歡在註釋中編寫問題編號，它更快更容易......並且它創建鏈接，因爲FishEye拾取更改集，所以Jira將顯示提交的問題。

我不能說如何Git/Stash組合或SVN與YouTrack/Mingle在這裏工作。但是在RTC中，將工作項附加到提交的工作流成爲了這個巨大的開銷，所以我們停止使用它=不值錢的功能。

然後是系統的整體計劃，工作項目，scrum等部分......我唯一會喜歡的部分是它不時給我的笑聲。除此之外，它幾乎是無用的...去Jira + GreenHopper，樂樂，YouTrack，而不是...

有趣的事情之一是，IBM試圖出售這個「集成」，你有多少節省。 。由於這些解決方案如此廣泛，有很多很好的解決方案，在那裏你可以設置它並且不必碰手指，直到你決定升級到該軟件的新版本。除了所謂的「管理員所節省的時間」之外，還有十倍的時間讓他們跑來跑去，幫助理清RTC似乎帶來的許多問題。

所以我會建議針對RTC。而Github，Codeplex，Bitbucket等已經證明Git，SVN等事實上確實在規模上......