Java のベストプラクティス

アプリケーションを最新の状態に保つことは、重要かつ困難になっています。このドキュメントでは、Java デベロッパーが DevOps プラクティスを始めるための基本的な手順について説明します。このリストがすべてを網羅しているわけではありません。これらのアイデアのほとんどは、ベストプラクティスの概要をより詳しく説明する DORA DevOps の調査と評価の研究から得られたものです。その他の出典には、Nicole Forsgren 博士、Jez Humble、Gene Kim による Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations、Titus Winters、Tom Manshreck、Hyrum Wright による Software Engineering at Google などがあります。

このページを読む前に、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 [コンテナ] [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、GKE クラスタ）

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

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

Compute Engine を使用する

これはアプリケーションに大きく依存する傾向があります。スタートアップスクリプトを使用することをおすすめします。アップグレードするには、スクリプトを更新する必要があります。

App Engine フレキシブル環境

Java 8 のみをサポートします。

App Engine スタンダード

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

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