CORECの開発を担当しています。
これから何回かに分けて、『CORECを支える技術』と題してCORECの開発について書いてみようかと思います。
今回はチケット管理と構成管理との連携についてCORECでの取り組みをご紹介したいと思います。
毎週リリースのサイクルを維持するためのポイントは自動化
CORECは2014年3月17日に初回リリースをしてから、80回を超えるリリースを行っています。(2015年5月時点)
その内容は、機能追加からデザイン変更やバグフィックス、文言変更まで大小さまざまですが、ほぼ週1回のペースを守っています。それは、より早くフィードバックサイクルを回し、お客様に喜んでいただける機能の追加や改修をより早く届けたいと考えているからです。
このペースを維持するために、いくつかのツールを利用したりそれらを連携する仕組みを構築しています。
できるだけ自動化することによって生産性の向上とヒューマンエラーの極小化を目指します。
その一端を担うのがチケット管理と構成管理との連携です。
この仕組みがCORECの開発を飛躍的に安心・安全にしてくれます。
なぜ、チケット駆動開発と構成管理?
なぜ、チケット管理と構成管理が連携すると安心・安全になるのでしょうか?
「やった(ような気がする)」のヒューマンエラー
チケット駆動開発は、チケットが正しく完了しそれがリリースされる必要があります。
開発者にチケットを渡し、そのチケットの完了を各担当者に任せると、やはり人間ですからミスが発生することがあります。
たとえば、実装したつもりが実装していなかった、実装したがコミットせずにチケットを完了してしまった、といったことがあげられます。
チケットの対応確認は手間
ですので、管理する側はチケットの内容がリリースされるかどうかを確認する必要があります。
CORECでは構成管理からリリース対象を抽出してリリースするフローになっているので、
管理する側から見てリリースされるかどうかを確認する一番確実な方法は構成管理を確認することです。
しかし、手作業でチケットの一覧と構成管理のログを突き合わせて確認するのは、根気と注意力のいる作業です。
少なくとも私には無理です(^^;
だから、自動化!
そこで、構成管理から自動的に連携します。
構成管理にコミットされたことをチケットに反映することによって、チケット管理システムで対応状況を正確に把握できるようになります。
副次的な効果として、開発者側も対応してコミットしたものが自動的に”対応済み”に変わっていくとちょっとした達成感が得られるという心理的効果もあり、
、それが、コミットコメントにチケット番号を含める動機にもなるので、ログで対応内容が把握しやすくなりました。
使用しているツール
まずはどのようなツールを使用しているかを説明します。
- Backlog(チケット管理)
- git
- jenkins
Backlog
CORECではすべてのタスクをチケット化します。
そのチケットの管理にはBacklogというWebサービスを利用しています。
このチケットに割り振られたチケット番号がすべてのキーになります。
git
構成管理はgitを利用しています。
社内で管理しているサーバー上にあります。
CORECでは単純にgitを使うのではなく、git-flow(※)というブランチモデルを利用しています。
git-flowブランチモデル
このgit-flowはCORECのスピードを保つ一つの大きな役割を果たしています。
本番(master)・開発(develop)のブランチをキレイに保ちつつ、本番で発生した問題に対応するブランチ(hotfix)、
日々の機能開発をするブランチ(feature)が適正に管理できる素晴らしい仕組みです。
この仕組とgitの的確なマージのおかげで開発者は同時に走っている他の開発のことをほとんど意識することなく自分のペースで開発を進めていくことができます。
※参考:『いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識』(http://www.atmarkit.co.jp/ait/articles/1311/18/news017.html)
gitのルール
git-flowを利用することでgitの使い方はおのずと決まってきますので、gitを使う上で決めているルールは以下の5点ほどです。
- 開発作業はfeature/hotfixブランチで行うこと
- feature/hotfixのブランチ名にはチケット番号を使用すること
- コミットコメントにはチケット番号を含めること
- finishは第三者が行うこと
- developにマージするコードはテストが通るものであること
jenkins
皆さんご存知のCIツールです。
gitとBacklogの連携部分を担います。
連携の設定
featureがfinishされ、gitサーバーのdevelopにpushされると、git-hookからjenkinsのjobをキックしてビルドが開始します。
ビルドでは自動テストやメトリクスの取得など実施し、結果をIRCに通知します。
ビルドが成功した場合には、開発評価環境に自動的にデプロイします。
逆に失敗した場合にはBacklogに課題チケットが作成されるので他の開発者に冷ややかな目で見られることになります。
それでは実際の連携の方法を解説していきたいと思います。
すべて同じツールを利用していなくても、部分的にも利用できるところはあるかと思いますので、参考にしていただければと思います。
構成管理(git/git-hook)とジョブ管理(jenkins)
まずは構成管理が更新されたことをジョブ管理に通知します。
git(git-hook)側の設定
gitにはgit-hookというイベントトリガの仕組みが用意されています。
いろいろありますが、詳細はこちらを参照してください。
今回はpush後に呼ばれるpost-updateというトリガを利用します。
トリガを利用するには、gitリポジトリのルートパス以下のgithookフォルダにトリガの名称のファイルを置きます。
同じフォルダに.sampleファイルがあるのでリネームしてファイルを作成します。
[gitリポジトリのルートパス]/githook/post-update
例えば以下のようになります。この例ではブランチ名を取得してdevelopだったらjenkinsの”corec”jobをキックしています。
#!/bin/bash
BRANCH=$(git rev-parse --symbolic --abbrev-ref $1)
if [ "${BRANCH}" = "develop" ]; then
curl http://[jenkins-host]/job/corec/build
fi
jenkinsのjobの実行にアクセス制限をしていない環境では、こんな簡単なcurlコマンド1行でjobを実行できます。
jenkins側の設定と認証付きの連携の設定
jenkinsのjobの実行にアクセス制限を設定する場合は以下の2つの方法があります。
- jenkinsそのものにユーザー認証をつける
- jobの実行にパスワードをかける
jenkinsそのものにユーザー認証をつけるには、jenkinsの
Jenkinsの管理>グローバルセキュリティの設定から「セキュリティを有効化」して認証方法を選択・設定する必要があります。
その方法については、ここでは省略します。
以下、上記2つのアクセス制限を設定した場合のgit-hookとjenkinsの連携について説明します。
ユーザー認証情報(APIトークン)の取得方法
jenkinsそのものにユーザー認証をつけた場合、APIトークンが必要になります。
具体的には、APIトークンをパスワードとしてベーシック認証を行います。
- 実際にgitサーバーからアクセスするユーザでjenkinsにログインします。
- ヘッダーの右側にあるユーザ名のリンクをクリックすると、開発者というメニューが表示されます。
- 設定メニューをクリックします。
- 右のペインに「APIトークン」のカテゴリが表示されます。
- APIトークンの表示をクリックすると、APIトークンが表示されるのでそれを控えておきます。
job実行の認証情報(認証トークン)の設定方法
jobの実行にパスワードをかける場合、認証トークンが必要になります。
実行パラメータに認証トークンを渡します。
- jobの設定画面を開きます。
- ビルド・トリガのリモートからビルドのチェックボックスをチェックし、表示された認証トークンのボックスに任意の文字列を設定します。
ここに入力したものがそのままパスワードになります。
※ 認証トークンをjobに設定した時点で先ほどサンプルに書いたcurlコマンドではアクセスできなくなりますので、稼働中の仕組みを触る場合はご注意ください。
認証付きでjenkinsのjobをリモートから実行する方法
最後に取得した情報を元に[repos]/githook/post-updateを編集します。
curlでベーシック認証&POSTするように以下のように書き換えます。
#!/bin/bash
BRANCH=$(git rev-parse --symbolic --abbrev-ref $1)
if [ "${BRANCH}" = "develop" ]; then
# 認証トークンをパラメータとして送るのでPOSTにして、できればhttpsにしておいたほうが良い
curl -u corec_jenkins:[APIトークン] -X POST \
http://[jenkins-host]/job/corec/build?delay=0sec&token=[認証トークン]
fi
ジョブ管理(jenkins)-チケット管理(Backlog)
次にジョブ管理から、構成管理の更新をBacklogに通知します。
仕組みとしては、ジョブ管理の中でシェル(プログラム)を起動し、Backlogの提供しているAPIを叩きます。
以下の2つのステップで実現しています。
- 更新する対象のチケットの取得
- Backlogへ通知
それではそれぞれ説明します
1.更新する対象のチケットの取得
更新する対象のチケット番号はjenkinsの変更履歴を解析して取得します。
gitのlogから取得しても良かったのですが、jenkinsは場合によっては複数のリビジョンをまとめて対象にする場合があるで、jenkinsのjobで管理されている変更履歴から取得する方法を採りました。
jenkinsの変更履歴の取得にはjenkinsのリモートAPIを利用します。
http://[jenkins-host]/job/corec/[build-no]/api/json
このURLのレスポンスでビルドの情報がJSONで取得できます。
取得したjsonのchangeSet以下が変更履歴のリストになるのでその中からチケット番号を拾い出しています。
2.Backlogへ通知
Backlogへの通知はコメント登録をすることによって実現しています。
Backlogへの接続にはスペースIDとAPIキーが必要になりますが、取得方法は以下のとおりです。
- スペースID
Backlogのサブドメインの部分です。
https://[スペースID].backlog.jp
- APIキー
Backlogの個人設定のAPIタブを選択して登録ボタンをクリックすると生成されます。
BacklogのAPI
BacklogのAPIライブラリはこちらに各種言語のものが紹介されています。
CORECではBacklog4Jを利用しています。
Javaを選んだ理由は当時私が扱いやすいものを選びました(^^;
Backlog4Jでの接続とコメント登録は非常に簡単で数行で実装可能です。
その他、いろいろな操作ができますので、詳細はgithub - backlog4jを参照してください。
// Backlogへ接続
BacklogConfigure configure = new BacklogJpConfigure("[スペースID]").apiKey("[APIキー]");
BacklogClient backlogClient = new BacklogClientFactory(configure).newClient();
// ステータスを変更し、コメントを登録
UpdateIssueParams params = new UpdateIssueParams(issueKey);
params.status(Issue.StatusType.Resolved); //ステータスを処理済みにする
params.assigneeId([担当者のID]); //担当者を変更する
params.comment(comment); //コメントを付加する
backlogClient.updateIssue(params);
ちなみにコメントは以下のように登録しています。
Backlogに登録するコメントにビルドURLを含めておくことで同時になにがコミットされたのか参照しやすくなるのでお勧めです。
変更がdevelopにコミットされました.
commiter:corec taro
commitId:xxxxxxxxxx9c6bc1adf5d3319f8cb49598
comment :COREC-999 jenkins自動登録機能
refer :http://[jenkins-host]/job/corec/[build-no]/changes
jenkins Backlogプラグイン(おまけ)
jenkinsにはBacklogプラグインがあります。
いくつか便利だと思った機能をご紹介します。お試しください!
- jenkinsへのログインをBacklogユーザーで認証する。
- 変更履歴にチケット番号があると自動的にBacklogへのリンクにしてくれる。
先ほどのコメントのサンプルにあるようにBacklogに登録するコメントにビルドURLを含めておくと、Backlogとjenkinsの変更履歴が相互リンクできるようになります。 - 失敗ビルドの場合Backlogにチケットを登録してくれる。
- jobのメニューにBacklogへのリンクが表示される。
クリックするとBacklogのスペースに飛んでくれます。
まとめ
CORECを支える仕組みとして、今回はチケット管理(Backlog)と構成管理(git)をjenkinsでつなぐ仕組みと
その設定方法をご紹介しました。
それぞれの設定やコードは簡単なものだということがわかっていただけたかと思います。
しかし、これにより得られる生産性や安心感は絶大です。
もし、まだこのような連携をしていなければ、ぜひ試していただいて、得られる生産性や安心感を実感していただきたいと思います。
少しの手間を惜しんで多くの時間を無駄にしないように、自分の仕事の環境にこそITを導入しましょう!
次回の『CORECを支える技術』もお楽しみに!