讓開發人員使用SVN的最後一次成功構建工作

如果您使用Subversion，如何組織開發人員可以輕鬆地檢查最後一個工作構建並開展工作，而不是處理可能損壞的HEAD？讓開發人員使用SVN的最後一次成功構建工作

問題背後的想法如下。當許多開發人員同時在一個項目上工作時，可能會發生某人中斷構建或某些測試。持續集成有助於儘早發現這些情況，但並不能防止HEAD版本暫時中斷。因此，我想讓每個人都能夠輕鬆檢出並處理已知正在工作的最新修訂版本，並在需要進行提交時僅更新到HEAD。用SVN創建一個標籤似乎並不是這樣做的適當方式，因爲在SVN中，標籤是一個新的分支，在每次成功構建後都可以移動。你會如何做到這一點？

來源

2011-08-03 Hans-Peter Störr

如果您的開發人員遵循'update to head，運行本地構建/測試，簽入'的標準做法，那麼您破壞服務器構建的機會應該很渺茫......您可以讓您的構建更新一個成功的公共批處理文件/腳本，供開發人員使用，並對特定版本的trunk進行簽出（您成功構建的修訂版本） – forsvarir

@forsvarir：謹慎移動此評論的答案部分到實際的答案？ –

如果您的CI服務器通知所有開發者，即不僅僅是那些在構建失敗時破壞構建的人，您的開發人員可以通過觀察失敗的構建電子郵件並等到「構建固定的」電子郵件結束時避免提取破壞的頭部。如果開發人員需要更新（也許在休假之後），他們可以回到最後的良好修訂版本。大多數CI軟件都支持這個。我知道Jenkins提供了一個'最後的成功構建'鏈接。如果你想要一個網頁來顯示這個，就像@forsvarir建議的那樣，你可以輕鬆地抓取這個頁面。

來源

2011-08-23 01:42:52 Feasoron

即使我使用SVN，由於它允許多個開發人員進行多個結帳，無論是誰在文件中籤入，都需要檢查並與以前的版本進行適當的比較。

假設在未來的構建，如果代碼休息，我們可以很容易地將其恢復..

來源

2011-08-03 09:20:47 gmhk

我不明白這是如何回答問題的。也許你可以詳細說明。 – forsvarir

如果你的開發人員以下的標準做法「更新頭，運行本地編譯/測試，籤」，然後你有一個破碎的服務器構建的機會應該是相當渺茫...

這就是說，你可以讓你的構建更新公共批處理文件/腳本成功，這是由您的開發人員使用，並簽出一個主幹的特定修訂版（您成功構建的修訂版）。所以，成功的打造你更新結賬命令是這樣的：

svn co https://<ServerPath>@RevisionNumber

凡RevisionNumber，服務器在結賬時運行要麼存儲，或致電svn info並提取Revision:值獲得

來源

2011-08-03 11:12:34 forsvarir

從純粹的技術角度來看，問題在於，您正試圖根據持續集成環境中的構建結果協調源代碼管理的行爲，這種環境有點回到前面。我不知道有什麼方法可以使開發人員根據CI構建結果從同一路徑的早期版本中獲取。

但實際上，這是一個開發實踐問題。開發人員不應該犯下「打破構建」的代碼，並且已經寫了很多關於應該拋出給那些人的懲罰的代碼:)

但是當然，一個本地構建可以成功，集成回幹線的代碼可能會失敗。這就是爲什麼像TeamCity這樣的產品具有「個人構建」的概念，因此可以針對主幹構建正在進行的工作，並且只有在構建成功後才能進行。

因此，簡而言之，您的問題是已知和認可的，並且存在解決此問題的工具和實踐的組合。但是不包含包括禁止基於構建結果的代碼拉取。

來源

2011-08-03 11:22:43

我實際上並沒有考慮禁止任何事情 - 而是很容易找到一個已知可以在出現問題時正常工作的修訂版本。（順便說一句，如果你使用其他工具或更復雜的版本控制系統，你實際上是禁止拉錯不正確的代碼。:-) –

所以，如果這只是發現最後一個已知良好構建的問題，爲什麼不檢查CI服務器第一？順便說一句 - 哪些VCS系統禁止拖拽不正確的代碼？ –

如果這確實是一個例外，建議開發人員在CI服務器網頁上找到上次成功構建/部署的修訂版本號，並建議在出現問題時返回此修訂版號。那麼這個問題就可以解決，而不會打擾其他人。

來源

2011-08-05 11:39:19

讓開發人員使用SVN的最後一次成功構建工作

回答

相關問題