我們正在寫一個項目。新增 SpringBoot 並設定 CI 流程 - 《Java 專案從 A 到 Z》

有關建立 Java 專案的系列文章中的一篇文章（其他資料的連結位於最後）。其目標是分析關鍵技術，結果是編寫一個電報機器人。 問候，親愛的讀者。正如前一部分所述，我們將按計劃進行。我們已經創建了一個項目，是時候用程式碼填充它了。現在所有問題都將作為單獨的提交添加。我將在這裡描述所有必要的內容。如果我錯過了什麼或描述得不夠清楚，請在評論中提問，我會盡力回答。

我們寫JRTB-0M

在這個任務中，我們需要新增一個空的 SpringBoot 框架以供將來的工作使用。我們將按照SpringBoot + Flyway 的文章中的相同方式執行此操作。下載該項目，在 IDEA 中開啟它並建立一個名為JRTB-0的新分支。我在這裡描述瞭如何透過一個想法來做到這一點。這將使我們更容易追蹤未來的工作。您是否已經知道不再有主分支？現在它被稱為中立主。所以我們就習慣了。不過，說實話，我們總是可以將其重命名回 master。我們前往Spring Initializr並為我們的機器人創建一個 SpringBoot 框架。目前，提供的 boot sprint 的最新版本是 2.3.7，我們就採用它吧。我將分別描述以下設定：

• 專案：Maven 專案- 我們已經在這裡和這裡討論了 Maven 。因此，我將只額外描述我在之前的文章中沒有透露的內容。當然，如果有這樣的「白點」）
• 語言：Java - 這裡一切都很清楚。如果有願望，我們可以用 Kotlin 重寫這件事。我剛剛為自己買了一本書《Kotlin in Action》，我們將一起學習 Kotlin））
• Spring Boot：2.3.7 - 我們採用提供的最小版本來消除任何問題。這已經是一款完全現代的靴子版本了。

項目元資料：

• 群組：com.github.javarushcommunity - 在這裡我們選擇託管我們的儲存庫群組的網域。
• 工件：javarush-telegrambot - 專案的最大描述。
• 名稱：Javarush TelegramBot - 我們將在這裡完整地寫下它。
• 描述：從社區到社區的 Javarush 電報機器人- 這是該專案的更詳細描述。
• 套件名稱：com.github.javarushcommunity.jrtb - 在這裡您已經可以使用專案名稱的縮寫。現在專案將從這個包開始。為什麼這麼多？這樣當我們將其他項目新增到類別路徑時，它們將位於不同的套件中。每個人都有自己獨特的方式。這對於維護 OOP 原則非常重要。
• 包裝：罐裝是我們的標準）
• Java：11 - 我們將領先一步。我不認為我會在第八個 Java 之後使用創新，但就這樣吧。他不要求食物）…這個決定將來會給我們一個小復活節彩蛋）

我們暫時不會新增任何依賴項。我們不需要這個來完成這項任務。填寫完所有這些後，我們得到（這裡是生成項目的連結）：填寫完畢後，點擊生成並將​​存檔中的所有內部內容添加到我們的項目中。將文件新增至項目。結果，我們有了一個應用程式。要檢查它是否已組裝，請轉到終端並寫入： $ mvn clean package如果與此處相同，則一切正常：項目已組裝，並且 jarnik 已在目標資料夾中準備就緒。至此，描述中的任務已準備就緒。這很簡單，對吧？因此，我們提交並推送到我們的分支：我們在提交描述的開頭添加我們的任務名稱，以便稍後可以清楚地知道工作是在哪個任務的框架內完成的。點擊“提交並推送” ...我們再次檢查並檢查我們到底想要從本地存儲庫推送到遠端存儲庫的內容，並確保一切正常，然後單擊“推送”。我們的下一步是什麼？根據所有規則（可以在本文有關 GitHub 流程的部分中閱讀），您需要為主分支建立拉取請求，並等待團隊中的某人審查程式碼。由於我獨自一人，因此我將正式建立拉取請求並再次審查所有內容。我轉到儲存庫頁面，Github 已經知道我們有一個補充，並提供創建拉取請求：愛國者沒有障礙 (c) - 我們按照建議創建它。我們設定與我們正在處理的任務相同的標籤、項目，並填寫描述：點擊Create pull request。

設定 CI 流程

我們轉到創建的拉取請求：下面我們看到我們沒有配置持續整合（以下稱為 CI）。嗯，還沒配置，那又怎樣？為什麼我們需要 CI？CI到底是什麼？這大約是我們目前應該關心的問題清單。一般來說，CI是一個將程式碼合併到公共程式碼庫並在此之前運行專案建置的連續過程。所謂build（源自英文build）。每次建置專案時，我們都會確保專案已編譯，所有測試均已成功通過，此外，建置專案後，您可以將測試人員的自動測試新增至在此特定建置上執行的 CI 中。這樣，我們就更有信心新的更改會按我們的預期工作，並且不會破壞先前的功能。CI 也很好，因為它在更新程式碼庫後自動啟動。也就是說，我們將更改推送到分支中，然後流程開始 - 組裝、測試、自動測試和其他步驟。如果這些步驟中的任何一個失敗，則建置將被視為已損壞並且無法合併到主分支中。這正是我們現在要做的：我們將添加 GitHub Actions，它將在推送後運行我們的程式碼。GitHub Actions 非常適合我們的 GitHub Flow，因此我們將使用它來自動化我們的工作。該工具非常強大且龐大，但目前我們僅使用它來運行建置並檢查它是否已根據需要進行組裝。要啟用它，請在儲存庫頁面上找到「操作」按鈕並按照它操作：找到我們需要的持續整合工作流程：按一下「設定此工作流程」。接下來，我們被要求使用他們的模板：我們完全同意，讓我們稍微澄清一下一切：

# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven

name: Java CI with Maven

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build with Maven
      run: mvn -B package --file pom.xml

這表示 GitHub Action 在兩種情況下被呼叫：

1. 當推送到主分支。
2. 當在主分支中建立拉取請求時。

作業部分描述了將要執行的步驟。我們只有一步——建構。它表明我們的專案將使用命令mvn -B package --file pom.xml在 Ubuntu 中啟動。這正是我們在當地所做的。如果你想在這裡改變一些東西，請。我將使用這個模板，這對我來說就足夠了。我點擊「開始提交」，選擇「建立新分支」來設定流程，然後選擇「提議新檔案」。但是建置過程失敗了...如您所見，14 秒後失敗 - 建置。看起來好像發生了什麼事：讓我們繼續組裝並查看細節：它說我找不到這樣的記憶體。為什麼？啊啊啊，正是，正是！因為我們在 master 分支中建立了更改，但我們的任務尚未完成。這就是為什麼他沒有找到記憶體......因此，現在我們執行以下操作：我們將這些資料合併到主分支中，然後將主分支合併到JRTB-0中，然後一切都會順利。在 github 操作發生變更的拉取請求中，按一下合併拉取要求:並重複確認合併。接下來，Github 提示我們刪除我們工作的分支。我們不拒絕和刪除：接下來，我在SpringBoot的pull request中沒有找到如何從網站拉取主分支的更改，所以我們將透過IDEA手動完成。

步驟1：將master分支更新到本機儲存庫。

這個想法是到 master 分支，按 ctrl + t 並更新 master 分支：

步驟 2：將 master 分支的變更合併到 JRTB-0 分支。

讓我們轉到 JRTB-0 並將主要部分合併到其中。

第 3 步：推送更改。

按 ctrl + shift + k 並確認推播。現在我們正在等待構建通過，它會變成綠色！）但它又變成紅色了。它是什麼？我們查看操作日誌，發現 Java 版本不同步。在 GitHubActions 中它是 8，但我們使用 11：現在有兩個選擇：要么更正操作，要么將版本降低到第八個。在我看來，第一個選項更好、更正確。我們正在單獨的提交中進行更改：我們將不使用 Java 8，而是使用 Java 11。最後，一切順利，我們能夠為該專案設定 CI 流程。這樣的東西需要在初期就設定好，這樣以後就不用擔心了。現在您可以看到建置已經通過，您可以放心地合併：

設定儲存庫中分支的工作

您也可以在儲存庫中配置此類內容作為使用分支時的規則。我想讓主分支不能直接推送，而只能透過拉取請求，並且我想讓它在建置失敗時無法合併拉取請求（即，如果 GitHub Actions 在某個步驟）。為此，找到設置按鈕並選擇分支：目前分支沒有規則，所以讓我們通過添加規則按鈕添加新的規則：這裡有很多設置，每個人都可以做一些適合自己的事情。需要。為了使建置能夠在合併之前的拉取請求中成功通過，請新增一個複選框以在合併之前需要通過狀態檢查，並選擇我們需要的狀態 - 建置。現在就夠了：然後你可以更新這個方向盤，看看你還想要什麼。按一下“建立”以建立此方向盤。接下來，如果我們再次轉到拉取請求，我們可以看到我們的檢查現在被標記為必要：讓我們檢查我們的專案頁面，該頁面顯示所有任務狀態：您可以立即看到正在處理什麼任務。而且，工作已經完成，任務處於程式碼審查狀態。

關閉 JRTB-0

現在我們已經準備好了 Pull Request 並為其建立了 CI，我們需要完成最後一個階段：關閉任務，將其移至正確的狀態，在看板上查看我們專案的變更。我們的拉取請求已準備好合併到主控。在拉取請求中，按一下合併拉取要求按鈕：合併成功後，您可以將其刪除，通常會這樣做。我這樣做並不是為了讓您更容易看到分支/提交之間的更改。一旦拉取請求被合併，它就會自動在我們的專案板中完成：最後一步是透過指向拉取請求所在的連結來關閉問題（問題）：此問題會自動在木板。開始已經開始，第一個任務已經完成！

結論

看起來我們已經開始工作並編寫程式碼了，但是仍然需要設定。是的，這需要時間，但是當專案變得更大、更複雜並且您需要保證不會因為一次提交而破壞所有內容時，它會帶來百倍的回報。發生這一切的拉取請求可以在這裡找到。或許，當你閱讀時，它已經關閉了。這並不可怕：所有必要的資訊都將透過連結儲存。感謝大家的閱讀，很快再見。另外！

此系列所有資料的清單位於本文開頭。