この記事は、Jenkins configuration as codeシリーズの第4回です。

Jenkins configuration as codeを使用すると、Jenkinsマスターの設定を簡潔で宣言的なYAMLファイルとして作成し、コードとして管理できます。しかし、JenkinsのXML設定ファイルをコードとして管理し、Gitリポジトリに格納すれば、以前から同じことを実現できたのではないか？と思われるかもしれません。

設定の適用

XMLテンプレートを使用してJenkins configuration as codeを実装したことがある管理者なら、設定を変更するのがいかに難しいかを知っているはずです。設定を変更し、Jenkinsにディスクから設定をリロードするよう指示し、さらにリロードが完了するまで待たなければなりません。パイプラインは非同期的に実行されるので、うまくいけばビルドを中断することなく設定を変更できますが、Webユーザーインターフェイス（UI）が長い時間利用できなくなるので、開発チームにとってはやはり大きな問題です。

リロードが遅いことの副作用として、管理者はどうしても必要になるぎりぎりまで設定を再ロードするのを避けるようになります。そうすると、設定が上流の参照バージョンと同期しなくなり、さまざまな問題や不満が生じる可能性があります。その結果、「ささいな修正」については、次回夜間に設定を適用するまでの回避策として、Web UIで手動で変更を適用しておくようになります。

結果として、Jenkinsを2回設定する必要があるため（応急処置としてWeb UIで修正しておいて、後でXMLに変更を反映する）as code アプローチのメリットがまったくなくなります。

瞬きする間に

Jenkins configuration as codeは、このリロードメカニズムを使用しません。実際のところ、ディスク上のXMLについて関知もしません。Jenkins configuration as codeは、Jenkinsの設定ページをサブミットしたときに使用されるWeb UIのデータバインディングメカニズムをベースとしています。データバインディングメカニズムでは、内部的には、JSON形式のWebペイロードを設定の変更に変換します。Jenkins configuration as codeはこのメカニズムを真似ていますが、JSONペイロードの代わりにYAMLドキュメントを使用します。

JCasCの設定を適用すると、すべての設定フォームを一度にサブミットするのと実質的に同じ処理が実行されます。

実際に体験してみると、マスターの完全な再設定が1秒もかからず完了したのが信じられずに、思わず何回も「リロード」ボタンを押してしまうかもしれません。

では、この次は？

Jenkins configuration as code プラグインの詳細についてはプロジェクトのGitHubリポジトリを参照してください。コミュニティやコントリビューターとチャットするには、gitterチャネルに参加してください。または、 DevOps World/Jenkins World 2018で直接JCasCプロジェクトとその未来についてお話しましょう。

また、Jenkins configuration as codeの次回の投稿もお見逃しなく！

シリーズの他の回

パート1 ：Jenkins Configuration as Code：最初の一歩（ママ見て、すごいでしょ）

パート2：Jenkins Configuration as Code：機密データの扱い

パート3：Jenkins Configuration as Code：プラグインをどう扱うか

（この記事は、CloudBees社 Blog 「Jenkins Configuration as Code: Need for Speed!」2018年9月12日 Nicolas De Loof 投稿の翻訳記事です。）