4
在我工作的軟件開發環境中，我們有一組開發人員都在同一個（Java）代碼庫（當前使用SVN）工作。 我注意到，人們希望經常提交他們沒有「破壞構建」而構建的內容。所以出於這個原因，我正在尋找像Git和Mercurial這樣的工具，使分支和特別合併變得更加容易。持續集成工作流程理念
我看到的一件事是，如果開發人員提交'錯誤代碼'，那麼代碼就會被打破。作爲一個避免這種想法的想法，我想要一種具有「中間單一特徵」存儲庫的方法，該存儲庫僅僅是當前的「主」，只有該單一新功能的一個變更集。然後，在成爲主要代碼庫之前，可以自動測試這種「中間單一特徵」存儲庫（代碼質量，單元測試，手動代碼檢查等）。
所以我想到的工作流程看起來像這樣：
- 開發人員創建一個新功能並每天在本地提交。
- 經過一段時間後，開發人員完成並提交整個變更集以集成到「主」存儲庫中。
- 持續集成系統採用當前的「主」，應用更改集並檢查代碼（合併衝突，PMD，FindBugs，...），運行單元測試，檢查編碼風格等。
- 如果CI系統決定「壞代碼」，開發者被告知原因，開發者必須解決上述問題。在這種情況下，主存儲庫不變。
- 如果CI系統決定「足夠好」，那麼代碼將到達「首席開發人員」或「代碼審查人員」，他們會檢查所選解決方案並批准或拒絕該解決方案。
- 然後將批准的變更集包含到主存儲庫中，並供所有開發人員進行重定位/合併。
我對這種工作流程的一些問題：
- 你的事情，這將在實踐中很好地工作（即這是一個好主意或一個真正的新空房禁地之一）？
- 以前有沒有人和你一起工作過？親和的是什麼？
- 是否有一個'準備好運行'的腳本/程序/工具/ ...，可以在最短的時間內啓動這樣一個工作流程（或這個想法的變體）？
謝謝。
背景說明：
我已經在那裏建立內部類似的工作流程中的公司約13年前曾作爲開發商，他們有兩個每晚構建：
- 「生產'版本：主代碼庫
- '高級版本：主代碼庫包含所有新提交版本的所有更改文件。
因爲這是所有SCCS（鎖定編輯 - 解鎖模式）的基礎上沒有辦法'經常'，你有代碼更改和所有其他類型的討厭影響的死鎖。 我期待的主要是關於當時使用當今更好的工具的東西。
我讀的頁面，看來，如果「提交」的變化，則系統會立即開始運行。如果你想「經常提交」，但是隻想在你認爲完成時就開始工作，這是如何工作的。如果你使用測試驅動開發，你首先進行（和提交）故意「破壞構建」的測試，以顯示仍然需要添加的功能。 – 2009-07-10 11:38:03