2

我們有3個分支{開發,測試,發佈},並將爲每個分支設置持續集成。我們希望能夠爲每個分支分配構建質量,即開發 - 準備測試...構建質量

有沒有人有任何這方面的經驗,可以提供任何建議/最佳實踐方法?

我們正在使用TFS 2008,我們知道它具有內置的構建質量。它正是何時應用質量以及人們使用什麼樣的素質纔是我們正在尋找的。

感謝

:)

+0

您正在使用哪個版本控制系統? – 2009-07-02 14:16:45

+0

我剛剛編輯,包括TFS 2008(謝謝尼爾) – Burt 2009-07-02 14:20:32

回答

1

您的目標是在每個分支中獲得最高質量的可能性,並平衡驗證質量水平的負擔。

允許質量下降任何分支總是有害的。不要以爲你可以讓Dev分支下地獄,然後在合併前修復它。它不能很好地工作,原因有二:

  • 恢復是很難比預期。當一個分支嚴重破裂時,你不知道它是如何破碎的。這是因爲每個問題都隱藏了他人。在任何問題上取得進展都很困難,因爲你會遇到其他問題。

  • 讓質量下降爲您節省什麼。人們有時會說「質量,成本,時間表 - 選擇任何2」或類似的東西。這裏的錯誤假設是你通過允許質量下滑而「節省」。問題是,只要質量下降,「速度」 - 即完成工作的速度也會如此。好消息是,保持高質量並不需要額外花費,而且每個人都喜歡使用高質量的代碼庫。

你必須做出妥協是你花了多少時間驗證質量。

如果您很好地進行了測試驅動開發,那麼您將最終獲得一整套極其快速,可靠的單元測試。由於這些特質,您可以合理地要求開發人員在簽入之前運行它們,並在每個分支中定期運行它們,並要求它們始終通過100%。您也可以隨時進行重構,這可以讓您在項目的整個生命週期內保持高速度。同樣,如果您編寫自動化集成/客戶測試的好,那麼它們運行迅速且可靠,那麼您可以要求它們也經常運行,並且始終通過。另一方面,如果你的自動化測試是片狀的,如果它們運行緩慢,或者如果你經常以「已知故障」進行操作,那麼你將不得不放棄人們必須經常運行它們的頻率,我會花大量時間解決這些問題。它很爛。不要去那裏。

最糟糕的情況是,大多數測試不是自動的。你不能經常運行它們,因爲人們在這些事情上真的很慢。您的未發佈分支質量將受到影響,合併速度和發展速度也會受到影響。

0

評估構建的確定性和可重複的方式質量肯定是具有挑戰性的。我建議如下:

  1. 如果您設置自動迴歸測試,那麼所有這些測試應通過。
  2. 開發人員應該使用新安裝在官方和乾淨的測試平臺上的官方開發版本進行集成測試,並給出他們的個人蓋章。

當這兩個條目滿足特定開發版本時,您可以合理確定將此構建推廣到測試不會浪費您的QA團隊的時間。