Java のベストプラクティス

アプリケーションを最新の状態に保つことは、重要かつ困難になっています。このドキュメントでは、Java デベロッパーが DevOps の使用を開始するための基本的な手順について説明します。これはリストを完全に網羅するものではありません。これらのアイデアのほとんどは、ベストプラクティスの概要が包括的に示される DORA DevOps の調査と評価調査から得られるものです。そのほかに、以下の資料があります。「Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations」（Nicole Forsgren 博士、Jez Humble、Gene Kim著）; および 「Software Engineering at Google」（Titus Winters、Tom Manshreck、Hyrum Wright監修）

このページを読む前に、Java 開発環境の設定を読むことをおすすめします。

どの開発組織もニーズは異なりますが、基本的なシステムは次のいずれかの技術スタックを使用して構築できます。

技術スタックの例 1	技術スタックの例 2
ソースコード用の Cloud Source Repositories、GitHub、Bitbucket。アーティファクトとライブラリを最新の状態に保つ Whitesource RenovateBot。単体テスト / 送信前テスト用の Cloud Build 統合テスト用の Cloud Build デプロイ用の Cloud Build	ソースコード用の GitHub。アーティファクトとライブラリを最新の状態に保つ GitHub Dependabot。送信前テスト用の GitHub Actions 統合テスト用の GitHub Actions デプロイ用の GitHub Actions

これらのコンポーネントで構成されている簡単なシステムにより、品質とサイクル時間を改善できます。また、最新のバグ修正やセキュリティアップデートを使用して、コードを簡単に最新の状態に保つこともできます。

バージョン管理

調査（17 ページ、14 ページ、31 ページ、60 ページ）では、ソースコードのバージョン管理と自動化およびテストを組み合わせることで、品質の向上など多くのメリットが得られることが判明しています。

Cloud Source Repositories [クイックスタート] は、ソースコードに無料の Git ワークフローを提供しています。
Artifact Registry [コンテナ] [Java パッケージ] は、ビルドされた Java アーティファクトの保存に適した場所です。

GitHub、Gitlab、Bitbucket もソースコードの保存先に適しています。

自動テスト

成功には、これらの手法の多くを使用する継続的テストが不可欠な場合があります。テストのベストプラクティスの詳細については、SRE Book の信頼性テストの章と Google Testing ブログをご覧ください。

Java デベロッパーが特に重視するのは、自動化された単体テストと統合テストです。JUnit、Testing with Spring、Apache Maven Surefire、Gradle Java テストは、Java デベロッパーに有用なリソースです。

継続的インテグレーション / デプロイの自動化

継続的インテグレーションとデプロイの自動化により、最新の DevOps ジョブを実行できます。ビルド、テスト、デプロイ

Cloud Build の [クイックスタート]、[Java Specific]、[デブロイ]、[トリガー] では、無料（1 日あたり 120 ビルド分）または低コストで簡単に使用できるビルドシステムが提供され、ほとんどのジョブで簡単にカスタマイズできます。す。
Tekton はオープンソースプロジェクトで、Cloud Build のアイデアをシステムに簡単に適応させることができます。
Spinnaker はオープンソースでマルチクラウドの継続的デリバリープラットフォームであり、ソフトウェアの変更を迅速に確信を持ってリリースできます。複雑なソフトウェアシステムをリリースしてロールバックするプロセスの管理に役立ちます。
GitHub's Actions は、テストのセットアップと GitHub でのテストを簡単に実行できるサードパーティのソリューションです。
Gitlab、Circle CI、Travis CI など、他にも多くのソリューションがあります。

Cloud クライアントライブラリ

Google サービスの使用方法は多数ありますが、Cloud クライアントライブラリページの手順を追うことをおすすめします。Java の場合、Libraries-BOM を使用すると、アーティファクトごとに互換性のあるバージョンを使用できます。

ご自身のバージョンのクライアントライブラリを選択すると、互換性のないアーティファクトが選択される可能性があります。これは、ダイアモンド依存関係の問題として知られています。それでも個々のライブラリを選択する必要がある場合は、一度に 1 つずつライブラリを更新して、更新によってエラーが発生したかどうかを確認します。最新バージョンは常にこのページに記載されているか、Maven-Central で検索すると知ることができます。

依存関係を最新の状態に保つ

悪意のある人から保護するには、依存関係を最新の状態に保つことが重要です。このために役立つサードパーティのツールが多数あります。

これらのツールを適切に構成すると、依存関係を最新の状態に維持できます。自動テストと継続的インテグレーション / 継続的デプロイを組み合わせると、フローは次のようになります。

依存関係の自動化は、ソース管理の変更を提案します。
継続的ビルドシステムは、変更をビルドしてテストします。
人間が提案を確認し承認することで、変更が承認されます（場合により他の変更と一緒に承認されます）。
変更が承認されると、継続的デリバリーシステムに提案が行われ、コードを本番環境にリリースできます（またはカスタムプロセスに沿います）。

サポートされている Java Runtime Environment（JRE）を使用する

JRE は Java Development Kit のサブセットであり、オペレーティングシステム上に配置され、Java アプリケーションの実行に必要なソフトウェアとリソースを提供します。ほとんどのユーザーは、本番環境で最新の LTS バージョンを使用して、更新、セキュリティ、バグ修正を利用できるようにしています。通常、コードを以前の JDK に対してコンパイルした場合でも、新しい JRE に更新することは可能です。

複数の JDK バージョンを使用する場合、SDKMAN! を使用すると、異なる JDK バージョンを使用、管理できます。

コンテナの使用（Google Kubernetes Engine、Cloud Run、Anthos クラスタ）

RenovateBot または DependaBot で Docker コンテナを使用している場合、bot は JRE と JDK の更新を定期的に提案します。JDK と JRE を同じバージョンのままにすることをおすすめします。

通常は、Jib を使用して Java アプリケーションをコンテナ化することをおすすめします。

Dockerfile を手動で更新した場合は、JRE を最新に変更して再ビルドするだけです。

Compute Engine を使用する

これは多くの場合、アプリケーション固有です。起動スクリプトを使用することをおすすめします。アップグレードするには、スクリプトを更新する必要があります。

App Engine フレキシブル環境

Java 8 のみがサポートされます。

App Engine スタンダード

Java 8 から Java 11 への App Engine アプリの移行

Java 開発キットの LTS バージョンを使用する

JDK は Java アプリケーションを開発するための一連のツールです。新しい言語機能は特定の JDK に関連付けられます。長期サポート（LTS）対応の JDK に使用状況を固定し、アプリケーションに適したタイミングで次の LTS バージョンにアップグレードすることをおすすめします。固定されたメジャー LTS リリースの最新のマイナーリリースを使用することをおすすめします。

ほとんどのユーザーは JDK と JRE の同期を維持する必要があります。場合によってはできないときがあり（JDK がサポートされていない場合などに）、新しい JDK でコンパイルして前の JRE で実行しなければならない場合もあります。

Maven でこれを行うには:

コードを記述する言語レベルとターゲット JRE を設定します。pom.xml ファイルを、xml <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> のように更新します（Java 8 の場合）。

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 の後からは削除されましたのでご注意ください。