ドリームパートナー

【最終回】Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜後編その2〜

wsadmin

jenkinsxのイメージ

いよいよ長期に渡り連載してきた本シリーズも最終回です！

後編その1 で予告した通り、前回作成した quickstart プロジェクト中のコードを修正し、production 環境へのリリース作業を実施し、最後に筆者が Jenkins X を実際に触って受けた印象を書いてみたいと思います。

[adinserter block="1"]

本記事では、前回の記事からの作業をそのまま引き継いだ形で記載しているため、まだ読まれていない方は先に 後編その1 から読まれることをお勧めします。

コードを修正して Pull Request を作ってみる

では、作成したリポジトリにブランチを作成して、コードを修正して Pull Request を作成してみましょう。
今回は、上記で確認できるレスポンスに、現在日時のフィールドを加える改修を実施してみます。

ブランチを作成して、コードを修正してみる

まず jx create quickstart 時にいたディレクトリ配下にリポジトリが存在するので、そのディレクトリへ移動して、ブランチを適当に切ります。
ジョブの初期設定では、master ブランチ、 PR- で始まるブランチ、feature で始まるブランチがジョブの CI 処理対象となっているため、ブランチ名はその規則に従うようにしましょう。

$ cd quickstart-spring-boot
$ git checkout -b feature/add-date-field

次に、GreetingController クラス内でレスポンスの内容として利用されている Greeting クラスを以下の様な内容に変更してみます。
(Date クラスの date 変数を追加しています)

package hello;

import java.util.Date;

public class Greeting {

    private final long id;
    private final String content;
    private final Date date; // 追加

    public Greeting(long id, String content) {
        this.id = id;
        this.content = content;
        this.date = new Date(); // 追加
    }

    public long getId() {
        return id;
    }

    public String getContent() {
        return content;
    }

    // このメソッドを追加
    public Date getDate() {
        return date;
    }
}

ファイルの編集が完了したら、git add/commit して push します。

$ git add -u
$ git commit -m 'add date field'
$ git push origin feature/add-date-field

次に、Web ブラウザで quickstart-spring-boot リポジトリへアクセスし、今回作成したブランチに関して Pull Request を作成します。

しばらくすると、Jenkins ジョブ上の Pull Requests タブに PR-1 というジョブが現れるはずです。
5分ごとにリポジトリスキャンが行われますが、お急ぎの場合ジョブ画面の左側にある Scan Repository Now ボタンを押しても同じ効果が得られます。

このジョブで実行されるビルドでは、以下の作業が行われます。

しばらく待つと、Pull Request でリクエストされたコードの動作を確認できる動作環境へのリンクが貼られたコメントが Pull Request に記載されます。

 

here の部分のリンクをコピーし/greeting を追加して、改修したコードで動作しているアプリケーションへアクセスしてみましょう。
以下のようなレスポンスを確認出来たら成功です！

{"id":1,"content":"Hello there, World!","date":"2018-09-21T08:54:27.814+0000"}

PR をマージする

master ブランチが更新され、リポジトリ作成時の初期コミット時に実施された作業と同等の作業が実施され、 staging 環境がアップデートされます。

[adinserter block="1"]

production 環境へリリースしてみる

以下のコマンドを実行します。

$ jx promote quickstart-spring-boot --env production --version 0.0.2

staging 環境と同じく、production 環境の構成情報を保持しているリポジトリに対してアプリケーション追加の PR、マージが自動で行われ、アプリケーションの公開が自動で行われます。

ビルドが完了したら、以下のコマンドを実行してみましょう。

$ jx get applications
APPLICATION            STAGING PODS URL                                                             PRODUCTION PODS URL
quickstart-spring-boot 0.0.2   1/1  http://quickstart-spring-boot.jx-staging.XXX.XXX.XXX.XXX.nip.io 0.0.2      1/1  http://quickstart-spring-boot.jx-production.XXX.XXX.XXX.XXX.nip.io

PRODUCTION という列にリリースしたバージョンが記載され、稼働中の Pod の情報、URL が新たに追加されているのが確認できるはずです。
また、production 環境の URL へアクセスしてみて、staging 環境と同様のレスポンスが返ってくることも確認してみましょう。

[adinserter block="1"]

Jenkins X を試用してみた感想

一通り Jenkins X の構築から quickstart プロジェクトを用いてのアプリケーションの修正・デプロイ時の挙動を見てきましたが、筆者が思った現状の Jenkins X に対する感想を箇条書きで書いてみたいと思います。

CI を用意する立場から見てみると、Jenkins X 内部で利用されている構成技術の数が多いので、稼働構成の把握と仕組みを理解するために必要となる時間を多く要すると感じました。
ただ、日頃から Jenkins を利用して開発物の CI/CD を実施していて、Jenkinsfile や Kubernetes に触れている人であれば、調査するにも手掛かりがまったくないという状態ではないので、今後の Jenkins X の進化に期待しましょう。

[adinserter block="1"]

まとめ

本連載では、CI/CD というものが何者であるかの説明に始まり、Jenkins X のインストール、プロジェクトの作成、実際の Git を用いた開発フローを行った場合に Jenkins X がどのように CI/CD を実施してくれるのかをご紹介しました。
アプリケーションの動作環境・デプロイを圧倒的に便利・安全に実現可能にする Kubernetes が出現してまだ数年ですが、CI/CD についてもこれだ！というベストプラクティスがない中、Jenkins X も今後に注目できるプロダクトの一つではないか、というのが筆者の感想でした。引き続き Jenkins X のプロジェクトをウォッチしていきたいと思います。

最後に、全編読んでいただいた方に感謝すると同時に、本連載がみなさまの CI/CD ライフに少しでもお役に立てれば幸いです。

＞Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜前編〜
＞Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜中編 〜
＞Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜後編その1〜

モバイルバージョンを終了