Nightly Builds：我爲什麼要這樣做？

Question

我爲什麼要做Nightly Builds？

Answer 1

每晚構建並不總是必要的 - 我認爲他們只對大型項目非常有用。但是如果你在一個大項目中，每晚構建一個檢查一切正常的好方法 - 你可以運行所有的測試（單元測試，集成測試），構建你的所有代碼 - 簡而言之，驗證什麼都不是在你的項目中破碎。

如果你有一個較小的項目，你的構建和測試時間將會縮短，因此你可以負擔得起更多的定期構建。

Answer 2

嗯......當然，我認爲這取決於您的項目。如果它只是你的愛好項目，沒有發佈，沒有依賴關係，沒有人，但你提交代碼，這可能是矯枉過正。

另一方面，如果有一組開發人員都提交代碼，那麼自動每晚構建將幫助您確保存儲庫中代碼的質量。如果某人爲所有其他人做了「打破構建」的事情，它很快就會被注意到。可以在不注意的情況下打破構建，例如忘記將新文件添加到存儲庫，每晚在中央位置構建都會很快檢測到這些文件。

當然還有其他可能的好處，我相信別人會提供這些好處。 :)

Answer 3

這也取決於在您的項目上工作的團隊的規模和結構。如果有不同的團隊依賴於其他API，那麼爲了頻繁集成而進行夜間構建可能很有意義。如果你只用一兩個隊友來砍掉它，它可能會也可能不值得。

Answer 4

我認爲他們對於超過1人的項目尤其重要。球隊需要儘快知道是否有人：

• 檢查不好的文件
• 沒有在文件中
• 檢查...

Answer 5

你應該做每晚構建以確保你的代碼庫保持健康。

夜間構建的副作用是它迫使團​​隊創建和維護一個完全自動化的構建腳本。這有助於確保您的構建過程被記錄並可重複。

自動版本是善於發現存在以下問題：

• 有人的東西，打破的東西進行檢查。
• 有人忘記檢查必要的文件或更改。
• 您的構建腳本不再有效。
• 你的打印機壞了。

每晚這樣做可以確保您在發生此類問題的24小時內發現此類問題。在您應該交付軟件之前24小時，找到所有問題比較好。

當然，您還應該爲每個每晚構建運行自動單元測試。

Answer 6

每晚構建僅適用於大型項目（當它在一天中經常需要很長時間才能構建時）。如果你有一個小型項目不需要很長時間就可以構建，你可以在你完成代碼的功能性部分的時候構建它，這樣你就可以知道你在程序中沒有搞亂任何東西。然而，更大的項目，以便構建項目只是讓你知道，一切都還在正常工作

Answer 7

我個人發現持續集成比夜間更重要的是這是不可能的建立：
http://en.wikipedia.org/wiki/Continuous_integration

我甚至在一個人的項目中使用它，它驚人地快速暴露問題並在那裏照顧他們。

Answer 8

實際上，您應該期望的是持續集成和自動測試（這比每晚構建還要進一步）。

如果您有任何疑問，您應該閱讀this article by Martin Fowler about Continuous Integration。總而言之，你想要儘早建立和測試，以便立即發現錯誤，以便可以修復錯誤，而在造成錯誤時你試圖達到的目標仍然是新鮮事物。

Answer 9

我實際上建議在每次檢入時都要建立。換句話說，我建議設置一個持續集成系統。

這種系統的優點和其他細節可以在in Fowler's article和on the Wikipedia entry等地找到。

根據我個人的經驗，這是一個質量控制問題：每次代碼（或測試，可以被視爲一種形式的要求）被修改，錯誤可能會蔓延。爲了確保質量，你應該做一個新鮮的因爲它將被運送並執行所有可用的測試。這種做法越頻繁，就越不容易形成一個殖民地。因此，每日（每晚）或連續的週期是首選。此外，無論您是將項目的訪問權限限制在開發人員還是更大的用戶羣中，夜間構建都可使每個人都處於「最新版本」，從而最大程度地減少將自己的貢獻重新合併到代碼中的痛苦。

Answer 10

任何構建自動化，總比沒有的構建自動化:-)

個人更好，我更喜歡的日常構建 - 如果這樣構建不工作，那麼每個人都圍繞得到它固定。實際上，如果可能的話，持續集成構建就是要走的路（即在每個簽入時建立一個基礎），因爲這樣可以最大限度地減少構建之間的變化量，從而可以輕鬆地分辨誰打破了構建也很容易修復構建。

Answer 11

有幾個原因，有些人會比其他人更適用

• 如果你的項目是由兩個或兩個以上的人
• 這是抓住了最新版本的代碼，一個很好的方式製作您在代碼
• ，如果你需要發送代碼到人每晚構建會給你一個穩定版本的當前狀態的時間不工作
• 每晚構建提供了一個切片

Answer 12

每晚構建是執行靜態代碼分析的理想選擇（請參閱qalab及其在Java世界中收集統計信息的項目）。不幸的是，這是很少做的事情。

Answer 13

你想要建立在的定期時間表上，以便發現開發人員之間的代碼集成問題。你希望這樣做的原因是，每週或者更長的時間表，而不是每週都會這樣做，就是你等待發現這些問題的時間越長，解決它們的難度就越大。在每次檢查（持續集成）時進行構建的做法只是將夜間構建過程轉化爲邏輯極限。

從長遠來看，具有可重複構建過程的副作用也很重要。如果你在一個有多個項目正在進行的團隊中工作，那麼在某個時候你需要能夠輕鬆地重新創建一箇舊版本，或許可以創建一個補丁。 :(

構建過程自動化程度越高，每次後續構建的存儲時間就越多，也需要構建過程本身脫離交付最終產品的關鍵途徑，這應該會讓您的經理感到開心。:)

Answer 14

我一直在做建設工程（其中包括）16年。我堅信建立早期，建立 - 經常持續集成。因此，我在項目中做的第一件事是確定它將如何構建（Java：Ant或Maven; .NET：NAnt或MSBuild）以及如何管理它（Subversion或某些其他版本控制）。然後，我將根據平臺添加持續集成（CruiseControl或CruiseControl.NET），然後讓其他開發人員鬆動。

隨着項目的增長，報表和文檔的需求不斷增加，最終構建需要更長的時間才能運行。此時，我會將構建版本拆分爲連續版本（在簽入時運行），只編譯和運行單元測試和每日構建，構建所有內容，運行所有報告並構建任何生成的文檔。我還可以添加標籤庫的交付版本，併爲客戶交付執行任何其他包裝。我將使用細粒度的構建目標來管理細節，以便任何開發人員都可以構建系統的任何部分 - 持續集成服務器使用與任何開發人員完全相同的構建步驟。最重要的是，我們永遠不會提供構建測試或未使用構建服務器構建的客戶。

這就是我做的 - 在這裏就是爲什麼我這樣做（爲什麼你也應該這麼做）：

假設你有一個典型的應用，與多個項目和幾個開發商。雖然開發人員可能會從一個共同的，一致的開發環境（相同的操作系統，相同的補丁，相同的工具，相同的編譯器）開始，但隨着時間的推移，他們的環境將會出現分歧。有些開發人員會虔誠地應用所有安全補丁和升級，而其他開發人員則不會。一些開發人員會添加新的（也許更好的）工具，而其他人則不會。有些人會記得在建築之前更新他們的完整工作空間;其他人只會更新他們正在開發的項目的一部分。有些開發人員會將源代碼和數據文件添加到項目中，但忘記將它們添加到源代碼管理中。其他人將編寫依賴於他們環境特定怪癖的單元測試。因此，您很快就會看到這種流行的「嗯，它在我的機器上構建/運行」的藉口。

通過擁有一個用於構建應用程序的單獨的，穩定的，一致的，已知良好的服務器，您將輕鬆發現這些類型的問題，並且通過從每次提交運行構建，您將能夠查明何時出現問題悄悄進入系統。更重要的是，因爲您使用單獨的服務器來構建和打包應用程序，所以每次都會以相同的方式打包所有內容。沒有什麼比開發人員將自定義構建版本發送給客戶更糟糕了，讓它工作，然後不知道如何重現自定義。

Answer 15

根據產品的複雜性，持續集成可能會或可能無法運行完整的測試套件。

想象一下，思科測試路由器時需要測試1000個不同的設置。要在某些產品上運行完整的測試套件需要時間。有時幾周。所以你需要構建出於不同的目的。每晚構建可以作爲更徹底的測試套件的基礎。

Answer 16

當我看到這個問題時，首先我搜索了Joel Spolsky's答案。有點失望，所以我打算在這裏添加它。

希望大家都知道Joel Test on Careers。

從他The Joel Test: 12 Steps to Better Code

3.博客你做每日構建？

當您使用源代碼管理時，有時一個程序員 意外檢查破壞構建的東西。 例如， 他們已經添加了一個新的源文件，並且它們的 機器上的所有內容都編譯得很好，但他們忘記將源文件添加到代碼 存儲庫中。於是他們鎖定了自己的機器並回家，不知所措，並且很快樂。但沒有人能工作，所以他們也不得不回家，不高興。

打破構建是如此糟糕（以及如此普遍），它有助於使日常構建 ，以確保不會引起破壞不被忽視。 在大型 團隊中，確保立即破損的一種好方法是 ，例如午餐時間每天下午進行日常生成。每個人在午餐前儘可能多地辦理登記手續。當他們回來時， 構建完成。如果它工作，太棒了！每個人都會檢查最新版本的源代碼並繼續工作。如果構建失敗，您可以修復它，但每個人都可以繼續使用預構建的源代碼版本 。

在Excel的團隊，我們有一個規則，誰打破了建立，作爲他們的 「懲罰」，負責照看建立，直到有人 別人把它弄壞了。這是一個很好的動機，不會破壞構建，並且可以通過構建過程輪換每個人，這樣每個人都可以學會如何工作。

雖然我沒有機會做日常搭建，但我非常喜歡它。

還是不服氣？看看這裏的概要Daily Builds Are Your Friend!!