Jenkinsに関するQ&A part2(2022 Jenkins Day Japan) | CloudBees|テクマトリックス

こんにちは。先日のJenkins Day Japan 2022の
Session A-4「Jenkinsはもう古い？様々な角度から見たJenkinsの現状の紹介」
に登壇した長久保です。セッション中もたくさんの質問ありがとうございました。

セッションの内容はオンデマンド配信として公開しておりますので、ぜひ視聴いただければと思います。

Jenkins Day Japan 2022 オンデマンド配信

今回はセッション内で回答しきれなかったものも含め、改めて皆様から頂いた質問について回答をさせていただきます。
なお、本ブログは質問についてPart2となっております。Part1はこちらをご覧ください。

質問１：JenkinsXとJenkinsは何が違う？

Jenkins XはJenkinsとどう違うのでしょうか? 「ぜんぜん違う」という話をきいたことがあるのですが、ご存知の範囲で教えていただけるとありがたいです。

Jenkins XはJenkinsからの派生プロジェクトではありますが、記載の通り、「ぜんぜん違う」ものととらえたほうが良いかと思います。
Jenkins XのチーフアーキテクトであるJames Strachanの定義によれば、Jenkins Xとは、基盤となるインフラストラクチャをあまり気にすることなく「Kubernetesでネイティブに継続的デリバリーを行うためのオープンソースの定型的な方法」とのことです。Kubernetesの利用が前提となったCI/CDツールです。
こちらでデモを確認できます。

ご覧の通り、UIから従来の「Jenkins」とは異なることが確認できるかと思います。ダッシュボードのUIなどはこちらのWebページでも確認が可能です。

Jenkins Xのコンセプトや、登場した理由については以下の弊社のブログが参考になるかと思います。

Jenkins Xの基礎知識

「Jenkins」とは名前はついており、「Jenkins」と「JenkinsX」は強い関連はあるものの、利用者目線で考えた場合は全く別のCI/CDツールと認識されたほうが正確かと思います。

質問２：as Code 環境としてパイプラインやJob DSLの使い分け

as Code 環境としては、pipelineのほかにJobDSLもあると思いますが、これらの違い、使い分けのポイント等はありますか？

パイプラインとJob DSLのそれぞれについて説明します。

パイプラインは開発プロセス、開発対象のCD/CDフローをJenkinsfileといったコードで定義するものです。Jenkinsfileは開発対象のソースコードとともにSCM上で管理され、開発者が定義することが多いです。

Job DSLはJenkinsのジョブの設定などジョブ自体をコードで定義するものです。ジョブだけでなく、ビューやフォルダを作成することもできます。それ以外にもConfiguration as Codeプラグインとともに利用して、ジョブの初期セットを作成するといった用途で用いられます。パイプラインとは異なり、Jenkinsの環境の管理者が定義することが多いです。

パイプラインが登場するまではJob DSLプラグインを用いてCI/CDフローをコードとして定義していたこともあるようです。しかしパイプラインという仕組みがある現在では、CI/CDフローを定義するのであればPipeline、Jenkinsのジョブ自体を定義するのであればJob DSLを用いるといった使い分けをされると良いかと思います。

パイプラインについて、弊社で記載している以下のブログも併せてご確認いただけると幸いです。

また、パイプラインに関してのオンライン講座も実施しています。パイプラインの基礎から、応用としての共有ライブラリの書き方までしっかりと学習することができるので、ぜひご受講ください。

Jenkinsトレーニング

質問３：APIトークンのセキュリティ

jenkinsのJOB APIを外部から呼ぶ際にparameterとしてAPIトークン情報も渡したいのですが、公開したくありません。非公開にしつつparameterとして渡す方法はありますでしょうか

Jenkinsのcredentialsの仕組みを使うと良いかと思います。
Jenkins側にAPIトークンを登録しておくことで、APIトークンの中身を外部から隠蔽した状態で、登録されているAPIトークンを利用できます。

以下に例を示します。

JenkinsにAPIトークンを登録する。
Jenkinsのダッシュボード > Jenkinsの管理 > Manage CredentialsにてAPIトークンを登録します。今回登録するのはAPIトークンですので、種類をSeacret textとして登録します。

ジョブを作成する
今回はパイプラインジョブとしてサンプルを作成します。
この際に以下の2つのDirectivesを利用します。

parameters：パイプラインをトリガーするときにユーザーが指定する必要があるパラメーターを受け取る。
environment：環境変数として、Jenkinsに登録したcredentialを参照する。

上記2つのDirectivesを用いて、サンプルパイプラインを以下の通り作成します。

pipeline {
    agent any
    parameters {
        string(name: 'API_TOKEN_KEY', defaultValue: '', description: 'Enter the key of your registered APItoken in the credentials field.')
    }
    environment {
      API_TOKEN = credentials("${params.API_TOKEN_KEY}") 
    }
    stages {
        stage('hoge') {
            steps {
                bat 'echo API_TOKEN:%API_TOKEN%'
            }
        }
    }
}

JenkinsのジョブをAPI経由で実行する
API経由でJenkinsのジョブを実行します。呼び出し方法についてはこちらのページ(Remote Access API)を参照ください。

curl -X POST --user nagakubo:*** http://localhost:8080/job/JenkinsDayJapan2022Sample/buildWithParameters?API_TOKEN_KEY=test_api_token

buildWithParametersを利用して、パラメータをジョブに渡します。この際にAPI Tokenを直接渡すのではなく、JenkinsのManage Credentialsに登録した際のIDを渡します。
以下がパイプラインの実行結果になります。Jenkinsのコンソール上もAPI Tokenはマスキングされた状態で出力されます。

このようにすると外部からはAPI Tokenを隠蔽した状態で、パイプライン内でAPIトークンを利用できます。

上記の例ではパイプラインを用いて説明しましたが、フリースタイルジョブでも同様にJenkinsのManage Credentialsに登録したAPI TokenのIDを外部から渡しての実行が可能です。

ぜひお試しください。

質問４：CI/CDとTDDの関係性について

CI/CD（CI/CD/CD）とTDD（Test Driven Development）の関係性についてご説明いただけますか。（CI/CDの観点からTDDは必須なのか、強く推奨されるのか、など。）

(こちらの質問は2022 Jenkins Day Japanではなく、CI入門ウェビナーでいただいた質問となります。)

関連付く項目が多いので同時に話題に挙がることは多いかと思いますが、CI/CDを実現する上でTDDは必須という事ではありません。

継続的インテグレーションの概念についてはMartin Fowlerさんの以下の表現が参考になるかと思います。

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
https://martinfowler.com/articles/continuousIntegration.html

チームのメンバーが頻繁にソースコードをSCMにマージするソフトウェア開発手法
通常は各自が少なくとも毎日マージし、1日に何度もマージすることになります。
各統合は自動ビルド（テストを含む）により検証され、統合エラーを可能な限り迅速に検出します。

例えば「開発締めにそれまでの開発物をまとめてコミットし、大量のコンフリクトを起こし、その時点まで自動テストが行われない」といった状態は継続的アプローチとは相反する状態と言えるでしょう。

開発物に対して必ずテストが存在するという点ではTDDと相性はいいと言えますが、TDDで言われるようなコードよりも先にテストが存在していて、「レッド・グリーン・リファクタリング」での開発プロセスが必須ではありません。

まとめ

Jenkinsに関するQ&A part2として、5個の質問に回答しました。
今年もたくさんの方に参加いただいたJenkins Day Japan2022。セッションの内容をオンデマンドでの視聴もできますので、ぜひご覧ください。

2023年も開催予定ですので、ぜひご覧いただければと思います！

Jenkins Day Japan 2022 開催レポート

Jenkins Day Japan 2022 オンデマンド配信