檢查持續集成

從代碼控制軟件中檢查代碼以執行持續集成或每晚構建時，您通常都會做什麼？你是否1）拉取最新的代碼，或者2）通過代表開發者最新測試代碼的標籤（即FUNCTIONAL）拉動？檢查持續集成

我想這個答案取決於人們通常如何使用他們的配置管理存儲庫。你是否打算只存儲「完整」的代碼。如果是這樣的話，如果一個開發人員正在從事一項任務一週左右，他/她將無法檢查任何內容，直到完成任務。然而，如果持續集成服務器只是通過一個知名標籤拉取而不是拉取最新代碼，那麼這將允許開發人員在頻繁檢查代碼時檢查代碼，因爲他們正在努力存儲他們正在進行的工作的歷史記錄。然後，一旦他們對這些更改感到滿意，他們可以使用FUNCTIONAL標記標記新代碼。

只是想知道最佳實踐。

感謝

來源

2009-10-21 dewald

你假設開發人員可以在一個任務，而不造成破損無法正常工作，但不一定是真實的，特別是如果他們運行一套單元測試每次提交之前，並避免測試失敗時提交。 – bdsl 2017-07-13 23:13:00

所以我們通常做的是有一個「建」分支，它的CI服務器生成了。我們將我們想要包含在夜間構建中的所有東西都合併到構建分支中，並且它將在那裏建立。

我們實際上並沒有針對構建分支進行開發，我們有開發分支用於保持尚未準備好發佈到測試環境的更改。

來源

2009-10-21 02:08:04 lomaxx

你使用什麼工具？它是否使連續分支和合並非常簡單？ – dewald 2009-10-21 02:24:48

我們使用TeamCity。 CI服務器實際上沒有進行任何分支和合並，這仍然由開發人員來完成。 CI服務器所做的是檢測對特定SVN分支的提交，並觸發構建。構建包括編譯應用程序，運行單元測試以及將應用程序部署到服務器上 – lomaxx 2009-10-21 05:40:17

我放出來了CI（更像是經驗法則）的主要建議：

有它從 HEAD/MASTER拉代碼。儘可能保持穩定，儘可能保持穩定。
沒有人可以向 HEAD/MASTER提交破損的代碼。如果發生這種情況，那麼意味着有人破壞了構建。
無論誰打破構建必須是致力於儘快修復它成爲可能。
讓您的CI以每個承諾爲基礎運行構建。所以，只要某人提交破碎的代碼到 HEAD，配置項將獲得它並打破構建。大部分CI的服務器，我見過支持這種做法操作。
您還可以讓您的CI在生成程序包時每晚生成並標記代碼。這也是一個很好的練習，你可以看到在世界各地的開源項目上的許多CI上都有。

我的一些經驗：我們的CI可以從HEAD/MASTER中獲取代碼。我們在這裏使用git，所以我們的開發人員總是很容易地在分支上工作並保持同步 - 但他們只能將穩定的代碼提交給HEAD/MASTER。

來源

2009-10-21 02:44:06 Macaubas

我同意上面的大多數觀點 - 一個謹慎的想法 - 我發現如果以每次執行的方式運行，很難獲得流暢的CI在一個同時在一個大型項目的幾個模塊上工作的多開發團隊。提交頻率往往會壓倒CI服務器，特別是如果你有很多測試。在這種情況下，嘗試批量生成一定數量的提交或按計劃運行。 – Nikhil 2009-10-21 03:45:00

正確的答案是基於你如何組織你的代碼。

如果主線總是被認爲是穩定/工作的，那麼你只需從中建立。

如果你有一個分支是「金」分支，然後...

在我們的商店，我們有三種分支：

主線//總可建，總是「準備好發佈一次QA完成」
發佈分支//金黃，釋放和釋放，能夠在任何時間
開發分支//其中凌亂手術一事無成

（當然要做到這一點需要很好的vcs。我們使用perforce，它有很棒的分支。）

我們從mainline和release分支做我們的連續建築。

HTH

來源

2009-10-21 03:33:50 Jonesome

檢查持續集成

回答

相關問題