第49回：より良いプログラムを書くために［成果物を管理する］

みなさんこんにちは。先月作成した苺栽培マシーンで順調に苺の苗が育ってきて、早くも花が咲きました。その後も続々と花芽が出てきているので、これは本当に苺三昧生活ができるのでは！？！？！？と皮算用が止まらない今日この頃です。

記事の目次

成果物を管理する

前回までで、gitリポジトリにコードをpushした後に、Jenkins上でテストの実行や結果を確認できるようになりました。今回は、Jenkinsで生成された成果物と、元になったソースコードを一貫して管理できるようにしていきます。

パッケージのバージョン番号管理

作成したパッケージを本番で使用する場合、バージョン番号の管理はとても大切です。もし異なる内容のパッケージに同じバージョン番号が付けられてしまったとしたら、バグの発生などのトラブルが起きたときに原因を探るのがとても大変です。ソースコードを管理しているリポジトリと、Jenkinsのビルド、成果物の3つが一貫して管理されていると理想的です。つまり、あるバージョンで問題が起きたときにいつビルドされたものかを確認し、さらにそのビルドに使われたソースコードがどれかを確認できるようにします。こうすることで、問題が起きたコードではどんな変更があったのか？ひとつ前のビルドではどうだったのか？といったことを簡単に調べることができます。

Jenkinsのビルド番号をパッケージのバージョン番号に含める

バージョン番号を一貫して管理する際にJenkinsのビルド番号を基準にするのはとても都合が良いです。なぜなら、ビルド番号には

- パッケージ（成果物）を作成する際には必ずJenkinsを通す
- ビルドの成否に関わらず、ひとつのビルドに対してユニークなビルド番号が割り振られる
- ビルドごとに順番に割り当てられるので前後関係がわかりやすい

という特徴があるからです。

Jenkinsでビルドする際にビルド番号をパッケージのバージョン番号に含めるのはとても簡単です。Jenkinsからコマンドを実行する際に、便利な環境変数をいくつか使用できます。その中にある BUILD_NUMBERが実行中のビルド番号になります。この環境変数をsetup.pyの中で使用します。

# -*- coding: utf-8 -*-

import os
import setuptools
from setuptools import setup, find_packages

# Jenkinsの環境変数として用意されているBUILD_NUMBERを使用する
version = '1.7.%s' % os.environ['BUILD_NUMBER']

setup(name='algorithm',
      version=version,
      description='package sample',
      package_dir={'': 'src'},
      packages=setuptools.find_packages(where='src'),
     )

生成するバージョン番号にビルド番号を含めるようにして、commitとpushをするとJenkinsが走り、ビルド番号付きのパッケージを出力します。

Jenkinsのビルド番号をリポジトリにタグ付けする

続いて、ビルドが成功した際に元になったコミットにビルド番号を紐付けます。これには、gitのタグを使用します。ビルド実行後にJenkinsからタグ付けをするには、ビルド後の処理にGit Publisherを設定します。

まず最初にリポジトに名前を付けます。ソースコード管理でGitリポジトリの高度な設定を選ぶと名前を設定できます。

名前を設定したら、一旦保存します（ここで保存しないと、次の段階で名前を使用することができません）。

続いて、ビルド後の処理の追加でGit Publisherを選びます。

ビルド成功時のみプッシュにチェックを入れ、プッシュするタグに "${BUILD_NUMBER}" を指定し、タグの作成にチェックを入れて対象のリモート名に先ほど設定した名前を入力します。

これで、ビルドに成功すると元になったコミットにビルド番号がタグ付けされます。

ビルド・トリガの変更

リポジトリにコードをpushしてからJenkinsのジョブを実行するためにビルド・トリガを使用していますが、この方法ではpush → ビルド → tagをpush → ビルドと無限ループに陥ってしまって都合が悪いので、ビルド・トリガの内容を変更します。

まず、ビルド・トリガの設定で「リモートからビルド」をオフにして、代わりに「SCMをポーリング」にチェックを入れます。このとき、スケジュールの内容は空のままにしておきます。

この機能を使用するためのアクセストークンを設定します。Jenkinsのダッシュボードからグローバルセキュリティの設定を選び、Git plugin notifyCommit access tokensでAdd new access tokenをクリックし、アクセストークン名を指定してGenerateを押すと生成されます。ここで生成されたアクセストークンは一度しか表示されないので、ほかの場所にメモしておきます。本記事で使用しているJenkinsは記事執筆専用環境のためアクセストークンも表示していますが、本番環境ではセキュリティの問題が発生しないよう、厳重に管理してください。

作成したアクセストークンを使用してJenkinsのビルドを実行するために、Gitリポジトリのpost-updateを変更します。

C:/Windows/System32/curl.exe -X POST "http://localhost:8080/git/notifyCommit?url=file:///C:/repo/algorithm&token=e550afd9688e389a9683406825648fc8"

URLにJenkinsで指定しているリポジトリを指定し、tokenで先ほど生成したアクセストークンを指定します。

ここまでできたらビルドを実行してみます。上手くいくと、パッケージもリポジトリもJenkinsのリビジョンと紐付いた形で管理できていることがわかります。

まとめ

これで、ソースコードと成果物をJenkinsを通して一対一で紐付けることができました。これができるとトラブルの際にも元のソースコードをあたるのが簡単になり、前後の差分から原因の切り分けをすることがとても簡単になります。また、コミットするたびに新しいパッケージができてバージョンがどんどん上がっていっても管理コストが上がることはないので、そこで頭を使わなくて良いメリットも大きいです。

第50回の公開は、2023年1月を予定しております。

痴山紘史

日本CGサービス（JCGS）代表

大学卒業後、株式会社IMAGICA入社。放送局向けリアルタイムCGシステムの構築・運用に携わる。その後、株式会社リンクス・デジワークスにて映画・ゲームなどの映像制作に携わる。2010年独立、現職。映像制作プロダクション向けのパイプラインの開発と提供を行なっている。新人パパ。娘かわいい。

TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）