私たちはプロジェクトを書いています。SpringBoot を追加して CI プロセスをセットアップする - 「A から Z までの Java プロジェクト」

Java プロジェクトの作成に関するシリーズの記事 (他の資料へのリンクは最後にあります)。その目標は主要なテクノロジーを分析することであり、その結果として電報ボットを作成することになります。 親愛なる読者の皆さん、こんにちは。前編で述べたように、計画通りに進んでいきます。すでにプロジェクトが作成されているので、そこにコードを入力します。これで、すべての問題が個別のコミットとして追加されます。ここで必要なことをすべて説明します。何かを見逃したり、十分に明確に説明していない場合は、コメントで質問してください。お答えできるよう努めます。

JRTB-0Mと書きます

このタスクでは、将来の作業のために空の SpringBoot フレームワークを追加する必要があります。SpringBoot + Flyway に関する記事で行ったのと同じ方法でこれを行います。プロジェクトをダウンロードし、IDEA で開き、JRTB-0という新しいブランチを作成します。ここでアイデアを通じてこれを行う方法を説明しました。これにより、今後の作業の追跡が容易になります。masterブランチが存在しないことはすでにご存知でしたか? 現在は、neutrally- mainと呼ばれています。それで私たちはそれに慣れます。ただし、正直に言うと、いつでも名前を master に戻すことができます。Spring Initializrに移動し、ボット用の SpringBoot フレームワークを作成します。現時点で、提供されているブート スプリントの最も若いバージョンは 2.3.7 です。それを採用しましょう。次の設定については別途説明します。

• プロジェクト: Maven プロジェクト- Maven については、こことここですでに説明しました。そのため、これまでの記事で明かせなかった部分のみ追加で記載させていただきます。もちろん、そのような「白い斑点」があれば）
• 言語: Java - ここではすべてが明確です。ご希望があれば、この件を Kotlin で書き直すこともできます。Kotlin in Action という本を購入したところです。一緒に Kotlin を学びましょう))
• Spring Boot: 2.3.7 - 問題を排除するために、提供されている最小バージョンを採用します。これはすでに完全に現代的なバージョンのブーツです。

プロジェクトのメタデータ:

• グループ: com.github.javarushcommunity - ここでは、リポジトリのグループがホストされているドメインを選択します。
• アーティファクト: javarush-telegrambot - プロジェクトの最大の説明。
• 名前: Javarush TelegramBot - ここに完全に書きます。
• 説明: コミュニティからコミュニティへの Javarush 用 Telegram ボット- ここにプロジェクトのより詳細な説明があります。
• パッケージ名: com.github.javarushcommunity.jrtb - ここではすでにプロジェクト名の略語を使用できます。これで、このパッケージを使用してプロジェクトが開始されます。なぜそんなにたくさんあるのでしょうか？そのため、他のプロジェクトをクラスパスに追加すると、それらは異なるパッケージに入れられます。それぞれが独自の方法で。これは OOP 原則を維持するために重要です。
• 包装：瓶詰めが標準です）
• Java: 11 - 一歩前進します。8 番目の Java 以降はイノベーションを使用しないと思いますが、そのままにしておきます。彼は食べ物を要求しません）...この決定は将来私たちに小さなイースターエッグを与えるでしょう）

今のところ依存関係は追加しません。このタスクにはこれは必要ありません。これをすべて入力すると、次の結果が得られます (ここに生成されたプロジェクトへのリンクがあります)。入力したら、「生成」をクリックして、アーカイブ内のすべての内部要素をプロジェクトに追加します。プロジェクトにファイルを追加します。その結果、アプリケーションができました。アセンブルされているかどうかを確認するには、ターミナルに移動して次のように記述します。 $ mvn clean packageここと同じものがあれば、すべて問題ありません。プロジェクトはアセンブルされており、jarnik はターゲット フォルダにすでに準備されています。この時点で、説明内のタスクの準備が整いました。シンプルですよね？したがって、コミットしてブランチにプッシュします。コミットの説明の先頭にタスクの名前を追加します。これにより、後でどのタスクの作業が完了したかがフレームワーク内で明確になります。[コミットしてプッシュ]をクリックします...もう一度、ローカル リポジトリからリモート リポジトリに何をプッシュするかを確認し、すべてが問題がないことを確認して [プッシュ]をクリックします。次のステップは何でしょうか? すべてのルール (この記事の GitHub フローに関する部分で読むことができます) に従って、メイン ブランチのプル リクエストを作成し、チームの誰かがコードをレビューするのを待つ必要があります。私は一人なので、正式にプルリクエストを作成し、もう一度すべてをレビューします。リポジトリ ページに移動すると、Github はすでに追加機能があることを認識しており、プル リクエストの作成を提案しています。愛国者にとって障害はありません (c) - 提案どおりに作成します。作業中のタスクと同じラベル、プロジェクトを設定し、説明を入力します。[Create pull request]をクリックします。

CIプロセスのセットアップ

作成されたプル リクエストに移動します。以下では、継続的インテグレーション(以下、CI) が設定されていないことがわかります。まあ、設定されていないので、どうなるのでしょうか？そもそもなぜ CI が必要なのでしょうか? そもそもCIとは何でしょうか？これは、現時点で私たちが懸念すべき質問のほぼリストです。一般に、CI は、コードを共通のコード ベースにマージし、その前にプロジェクトのビルドを実行する継続的なプロセスです。いわゆるビルド（英語の build から）。プロジェクトをビルドするたびに、プロジェクトがコンパイルされ、すべてのテストが正常に合格したことを確認します。さらに、プロジェクトのビルド後、この特定のビルドで実行される自動テストをテスターから CI に追加できます。こうすることで、新しい変更が期待どおりに機能し、以前の機能が損なわれないという確信が高まります。CIもコードベース更新後に自動で起動するので良いですね。つまり、変更をブランチにプッシュし、アセンブリ、テスト、自動テストなどのプロセスが開始されました。これらの手順のいずれかが失敗した場合、ビルドは壊れているとみなされ、メイン ブランチにマージできません。これがまさにこれから行うことです。プッシュ後にコードを実行する GitHub アクションを追加します。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 が次の 2 つの場合に呼び出されることを示しています。

1. メインブランチにプッシュが行われたとき。
2. プル リクエストがメイン ブランチで作成されたとき。

ジョブ セクションでは、実行される手順について説明します。ステップは 1 つだけです。ビルドです。これは、プロジェクトがコマンドmvn -B package --file pom.xmlを使用して Ubuntu で起動されることを示しています。これはまさに私たちが現地で行ったことです。ここを変更したい場合は、お願いします。このテンプレートを使用します。私にとってはこれで十分です。[コミットの開始]をクリックし、プロセスを構成する新しいブランチの作成を選択してから、新しいファイルを提案します。しかし、ビルド プロセスは失敗しました...ご覧のとおり、14 秒後に失敗 - ビルド。何かが起こったようです。アセンブリに進んで詳細を見てみましょう。そのような記憶が見つからなかったと表示されます。なぜ？ああ、まさにその通り！これは、master ブランチに変更を作成しましたが、タスクがまだそこにないためです。それが、彼がメモリを見つけられなかった理由です... したがって、次のことを実行します。このデータをマスターにマージし、次にメイン ブランチを JRTB-0 にマージすると、すべてがうまくいくはずです。github アクションの変更を含むプル リクエストで、[プル リクエストのマージ]をクリックし、[マージの確認]を繰り返します。次に、Github は、作業したブランチを削除するように求めます。拒否して削除しません:次に、Web サイトからメイン ブランチから変更をプルする方法が SpringBoot からのプル リクエストに見つからなかったので、IDEA を介して手動で実行します。

ステップ 1: master ブランチをローカル リポジトリに更新します。

アイデアは、master ブランチに移動し、ctrl + t を押して master ブランチを更新することです。

ステップ 2: master ブランチから JRTB-0 ブランチに変更をマージします。

JRTB-0 に移動して、メインのものをそこにマージしましょう。

ステップ 3: 変更をプッシュします。

Ctrl + SHIFT + K を押して、押したことを確認します。現在、ビルドが完了するのを待っているので、緑色になります!)) しかし、再び赤色になります。それは何ですか？アクション ログを確認すると、Java バージョンで同期が取れていないことがわかります。GitHubActions では 8 ですが、ここでは 11 を使用します。ここで、アクションを修正するか、バージョンを 8 番目に下げるかの 2 つのオプションがあります。最初のオプションの方が優れており、より正確であるように私には思えます。別のコミットで変更を行っています。Java 8 ではなく Java 11 で作業します。その後、最終的にすべてがうまくいき、プロジェクトの CI プロセスをセットアップすることができました。このようなことは、後になって心配する必要がないように、初期段階で設定する必要があります。これで、ビルドが成功したことがわかり、恐れることなくマージできるようになりました。

リポジトリ内のブランチを使用した作業のセットアップ

ブランチを操作するときに、リポジトリ内でルールとしてそのようなものを構成することもできます。メインブランチを直接プッシュできず、プルリクエストを介してのみプッシュできるようにしたいのですが、ビルドが失敗した場合（つまり、GitHub Actionsが失敗した場合）にプルリクエストをマージできないようにしたいと考えています。何らかのステップ）。これを行うには、[設定]ボタンを見つけて[ブランチ]を選択します。現時点ではブランチのルールがないため、[ルールの追加]ボタンから新しいルールを追加しましょう。ここには多くの設定があり、誰もが自分の好みに合わせて何かを行うことができます。ニーズ。マージ前にプル リクエストでビルドが正常にパスするようにするには、[マージ前にステータス チェックのパスを要求する] チェックボックスを追加し、必要なステータス (ビルド) を選択します。現時点ではこれで十分です。その後、このステアリング ホイールを更新して、他に必要なものを確認できます。「作成」をクリックしてこのステアリングホイールを作成します。次に、プル リクエストに再度アクセスすると、チェックが必須としてマークされていることがわかります。プロジェクト ページを確認してみましょう。すべてのタスク ステータスが表示されます。どのタスクが作業中であるかをすぐに確認できます。さらに、作業はすでに完了しており、タスクはコードレビュー状態にあります。

JRTB-0を閉じる

プル リクエストを準備し、その CI を作成したので、最後の段階を完了する必要があります。タスクを閉じ、正しいステータスに移動し、ボード上のプロジェクトの変更を確認します。プル リクエストはマスターにマージする準備ができています。プル リクエストで、[プル リクエストをマージ]ボタンをクリックします。マージが成功したら、削除できます。通常は削除します。ブランチ/コミット間の変更を確認しやすくするためにこれを行うわけではありません。プル リクエストがマージされるとすぐに、プロジェクト ボードで自動的に完了になります。最後のステップは、そのプル リクエストへのリンクを使用して課題 (課題) を閉じることです。この課題は、プロジェクト ボードで自動的に完了になります。ボード。始まりがあり、最初のタスクは完了しました。

結論

すでに作業とコードの作成を開始しているように見えますが、設定はまだ必要です。はい、時間はかかりますが、プロジェクトがより大きく複雑になり、1 回のコミットですべてを壊さないという保証が必要になると、その効果は 100 倍になります。このすべてが行われるプル リクエストは、ここから入手できます。おそらく、あなたが読んでいるときには、すでに閉じられているでしょう。心配する必要はありません。必要な情報はすべてリンク経由で保存されます。読んでいただきありがとうございます。またお会いしましょう。さらに！

シリーズのすべてのマテリアルのリストは、この記事の冒頭にあります。