Java 最佳做法

保持應用程式在最新狀態已成為重要但困難的任務。本文提供一些基本步驟，協助 Java 開發人員開始採用 DevOps 做法。這份清單僅列舉部分例子，並未包含所有情況。這些想法大多來自 DORA 開發運作研究與評估研究，可提供最佳做法的完整概覽。其他來源包括：Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (ACCELERATE：精益軟體與 DevOps 背後的科學：建構及擴大規模的高效能技術機構) 一書，作者為 Nicole Forsgren 博士、Jez Humble 和 Gene Kim；以及 Software Engineering at Google (Google 的軟體工程) 一書，由 Titus Winters、Tom Manshreck 和 Hyrum Wright 策劃。

建議您先閱讀「設定 Java 開發環境」，再閱讀本頁面。

每個開發機構的需求都不盡相同，但您可以使用下列其中一個技術堆疊，建構基本系統：

技術堆疊範例 1	範例技術堆疊 2
Cloud Source Repositories、GitHub 或 Bitbucket 中的原始碼。 Whitesource RenovateBot，可確保構件和程式庫維持最新狀態。 使用 Cloud Build 進行單元 / 預先提交測試 使用 Cloud Build 進行整合測試 使用 Cloud Deploy 進行部署	GitHub 原始碼。 GitHub Dependabot，可確保構件和程式庫維持最新狀態。 用於預先提交測試的 GitHub Actions 用於整合測試的 GitHub Actions 用於部署作業的 GitHub Actions

使用這些元件建構的系統可讓您提升品質和週期時間。您也可以藉此讓程式碼保持在最新狀態，並取得最新的錯誤修正和安全性更新。

版本管控

研究 (第 17 頁、第 14 頁、第 31 頁和第 60 頁) 發現，原始碼的版本控管搭配自動化和測試，可預測品質提升，並帶來許多其他好處。

• Cloud Source Repositories [快速入門] 提供免費的Git 原始碼工作流程。
• Artifact Registry [Containers] [Java Packages] 是存放建構完成的 Java 構件的絕佳位置。

GitHub、Gitlab 和 Bitbucket 也是存放原始碼的好地方。

自動化測試

測試自動化對於您能否成功運用上述大部分技術至關重要。如要進一步瞭解測試最佳做法，請參閱 SRE Book 的「Testing for Reliability」一章和 Google Testing 網誌。

Java 開發人員主要關注自動化單元測試和整合測試。JUnit、使用 Spring 進行測試、Apache Maven Surefire 和 Gradle Java 測試都是 Java 開發人員的實用資源。

持續整合 / 部署自動化

持續整合和部署自動化是現代開發運作工作的基礎。建構、測試及部署。

• Cloud Build [快速入門導覽課程] [Java 專用] [部署] [觸發條件] 提供免費 (每天 120 分鐘的建構時間) 或低成本的易用建構系統，可輕鬆自訂以執行大多數工作。
• Tekton 是一項開放原始碼專案，可讓您將 Cloud Build 的概念套用至自己的系統。
• Spinnaker 是開放原始碼的多雲端持續推送軟體更新平台，可協助您安心且迅速地發布軟體變更。有助於管理複雜軟體系統的發布和回溯程序。
• GitHub 的 Actions 是第三方解決方案，可讓您設定測試並在 GitHub 上執行。
• 此外，還有許多其他解決方案，例如 Gitlab、Circle CI 和 Travis CI。

Cloud 用戶端程式庫

使用 Google 服務的方法有很多種，但建議按照「Cloud 用戶端程式庫」頁面的操作說明進行。如果是 Java，程式庫 BOM 可協助確保您使用的每個構件版本都相容。

如果您選擇自行挑選用戶端程式庫版本，可能會選到不相容的構件。這就是所謂的菱形依附元件問題。如果還是必須挑選個別程式庫，請一次更新一個程式庫，並測試更新是否導致錯誤。最新版本一律會列在這個頁面上，或是在 Maven-Central 中搜尋即可找到。

確保依附元件為最新版本

為防範惡意人士，請務必將依附元件維持在最新狀態。有許多第三方工具可協助您完成這項作業：

• GitHub 的 DependaBot
• Whitesource RenovateBot
• Snyk

只要正確設定這些工具，就能確保依附元件維持在最新狀態。結合自動化測試和持續整合 / 持續部署後，流程如下：

• 依附元件自動化會建議變更來源控制項。
• 持續建構系統會建構及測試變更。
• 人工審查提案，如果可接受，就會接受變更，可能還會接受其他變更。
• 變更獲得核准後，系統會向持續交付系統提出提案，將程式碼發布至正式版。(或遵循自訂程序)。

使用支援的 Java Runtime Environment (JRE)

JRE 是 Java Development Kit 的子集，位於作業系統頂端，提供執行 Java 應用程式所需的軟體和資源。多數使用者偏好在正式環境中使用最新的 LTS 版本，以便取得更新、安全性修正和錯誤修正。即使程式碼是根據較早的 JDK 編譯，通常還是可以更新至較新的 JRE。

重要事項： 在某些情況下，使用其他 JRE 會導致中斷，最常見的情況是使用需要特定版本的 Java 應用程式伺服器時。

如果您使用多個 JDK 版本，SDKMAN! 可協助您使用及管理不同 JDK 版本。

使用容器 (Google Kubernetes Engine、Cloud Run、GKE 叢集)

如果您使用 RenovateBot 或 DependaBot 搭配 Docker 容器，機器人會定期建議更新 JRE 和 JDK，建議您將 JDK 和 JRE 保持在相同版本。

如果手動更新 Dockerfile，只要將 JRE 變更為最新版本，然後重建即可。

使用 Compute Engine

這類問題通常與特定應用程式有關。建議使用啟動指令碼。如要升級，請更新指令碼。

App Engine 彈性環境

僅支援 Java 8。

App Engine 標準環境

請參閱「將您的 App Engine 應用程式從 Java 8 遷移至 Java 11」。

使用 Java 開發套件的長期支援版本

JDK 是一組用於開發 Java 應用程式的工具。新語言功能與特定 JDK 相關。建議您將使用情況固定在長期支援 (LTS) 的 JDK，並在適合應用程式時升級至下一個 LTS 版本。建議您使用釘選主要 LTS 版本的最新次要版本。

大多數使用者都會希望 JDK 和 JRE 保持同步。有時這並不可行 (例如 JDK 不再受支援時)，您需要使用較新的 JDK 編譯，並在較舊的 JRE 上執行。

如要使用 Maven 執行這項操作，請按照下列步驟操作：

設定要編寫程式碼的語言層級和目標 JRE。按照以下方式更新 pom.xml 檔案 (適用於 Java 8)： xml <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target>

如要更新為 Java 11，請將其變更為：

    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>

如果您使用 Gradle，請將 Java 8 的 build.gradle 檔案更新為：

compileJava {
  sourceCompatibility = 1.8
  targetCompatibility = 1.8
}

或是 Java 11：

compileJava {
  sourceCompatibility = 11
  targetCompatibility = 11
}

請注意，Java 8 之前的版本有 1. 前置字元 (Java 7 為 1.7，Java 8 為 1.8)，Java 8 之後則沒有。