問候,同事們!厭倦了強迫您的電腦不斷建立專案?那麼這篇文章適合您! 在這篇文章中,我將嘗試簡要而清晰地介紹有關持續整合(以下簡稱 CI)的資料,我將回答諸如「它是什麼?」、「為什麼?」之類的簡單問題。為什麼?” 我將給出一個測試項目的例子。本文針對有經驗的用戶,至少熟悉建置系統:Maven,知道如何使用Git,並知道如何將專案推送到GitHub;
“什麼是持續集成?”
讓我們看看Wiki是如何回答這個問題的: 持續整合(CI,英文Continuous Integration)是一種軟體開發實踐,包括每天多次將工作副本合併到公共主開發分支中,並為早期專案執行頻繁的自動化建置。檢測潛在缺陷並解決整合問題。 很可怕,不是嗎?讓我們嘗試用簡單的語言解釋這個術語: 持續整合是一種用於在某些機器上使用某些配置建置和自動測試軟體的系統,以檢測錯誤和不相容性。 好吧,沒問題,我們已經弄清楚了,但是出現了以下邏輯問題:為什麼我們需要 CI?
讓我們假設您正在編寫一個大型項目,並且需要添加/更改功能。您成功編寫了它,編寫了測試,啟動了它,一切似乎都很好,但事實並非如此。在某些情況下,一個功能的變更會影響另一個功能,另一個功能會影響第三個功能,依此類推,直到錯誤出現在某個地方並發生錯誤。是的,你可以說這很可能是一個設計很糟糕的項目,你可能是對的,但如果不是,而且這些連接真的應該存在呢?如果您多次編寫和創建一個專案(這種情況經常發生)怎麼辦?您對新編寫的功能進行了測試,並且得到了積極的結果。你很快就做出了承諾,然後推到了某個地方,並且已經在考慮如何在家抽雪茄,喝昂貴的威士忌,但沒有。唉,你的同事或老闆,無論是誰,都會說由於你的提交,整個構建崩潰了。你一臉茫然地說你是一名程式設計師,你什麼都測試過。但通常根本沒有時間不斷測試整個項目,並且您只測試了所做更改的程式碼段,而不是整個程序集。這就是 CI 為我們提供幫助的地方。每次推送任何資源時,CI 都會從頭開始建置您的項目,執行所有測試,並且只有當所有測試通過並且專案建置完成時,建置才會收到通過狀態。否則你就有機會東山再起,看看到底出了什麼問題。因此,是時候問一個問題“為什麼是這樣而不是其他情況?” 並且看看軟體的實現。 範例 正如我已經說過的,本文是針對那些熟悉 Maven 和 Git 的人。因此,我希望你知道除了設定 CI 等之外我是如何做的以及做什麼。-
首先,讓我們建立一個簡單的 Maven 測試項目,並在其中建立一個列印「Hello World!」的類別。並執行一些簡單的操作,讓我們為這個類別寫最簡單的測試。
因此,我們應該有一個原始的專案結構:
所有來源都將在我的 GitHub 上。你在 Main 中寫什麼以及會有什麼測試並不重要。
-
我們將專案推送到 GitHub。
-
有趣的來了。對於 CI,我選擇了Travis CI,因為它的可用性和可靠性。Travis 使用 GitHub 託管其原始碼。
因此,請造訪Travis CI網站並透過 GitHub 登入。在設定檔中我們連接我們的項目:
每次按下按鈕時,一切都已準備好進行組裝,但問題是如何組裝?
-
我們回到我們心愛的 IDEA 並創建一個.travis.yml文件
該文件負責 Travis 建置配置。讓我們看看最流行的設定:
- 您需要指定專案實施的語言;
- 指定目錄的路徑以使建置更快;
- 指定有關組裝成功或不成功的通知方法。
典型的 Travis 配置應該是這樣的:
# https://docs.travis-ci.com/user/languages/java/ language: java jdk: oraclejdk9 # Improve Build Speed https://dzone.com/articles/travis-ci-tutorial-java-projects cache: directories: - $HOME/.m2 # Notifications https://docs.travis-ci.com/user/notifications/ notifications: email: recipients: - qThegamEp@gmail.com on_success: always # default: change on_failure: always # default: always
為了清楚起見,我添加了帶有連結的評論。
-
我們再次推送到 GitHub 並打開Travis網站,選擇專案並監控建置。結果,我們收到有關建置成功的通知:
另外,在該網站上,我們可以看到一個徽章,其中包含我們專案的成功組裝,我們可以將其插入到我們的 README.md 中:
GO TO FULL VERSION