検索
連載

Redmine×Gitのハーモニーは涙のチケット駆動開発!?かんばん!〜もし女子高生がRedmineでスクラム開発をしたら(6)(3/3 ページ)

本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。

Share
Tweet
LINE
Hatena
前のページへ |       

「マージ」によるチケットのクローズ

まいん

ブランチで開発した場合、最終的にブランチのコミットはmasterブランチなどのメインの開発で利用しているブランチ(ここでは「masterブランチ」とします)へ反映するの。これを「マージ」と呼ぶんだよ。


まいん

マージによってブランチでの変更内容がmasterブランチなどへ反映されるよ。masterブランチへマージする前には、レビューやテストを行って問題ないことを確認してからマージするといいよ(図11)。


図11 ブランチのマージの概念図
図11 ブランチのマージの概念図
亜琉美

masterブランチへマージすれば、ストーリーの実装などの1つの作業が終わったことになるので、チケットを終了にして閉じます。


ぷりん

チケットを終了にするときは、やっぱり「チケットは衰退しました」とかメッセージを入れるのかなぁ。「Ticket To Ride」 ならぬ「Ticket To Decline」で、まさに「涙の乗車券」だね……(T_T)。


亜琉美

「ブランチをマージしてからチケットを閉じる」と説明しましたが、「Redmine Git Branch Hook」(後述)というマージ時に自動的にチケットをクローズするプラグインがあります。例えば、先ほどコミットしていったstory/#16ブランチを次のようにしてmasterブランチへマージします。


$ git checkout master
(masterブランチへ移動)
$ git merge --no-ff story/#16
(masterブランチへstory/#16ブランチをmasterブランチへマージ)
$ git push
亜琉美

マージした状態で、リポジトリの状態を確認すると、図12のようになります。


図12 ブランチがマージされたリポジトリの様子
図12 ブランチがマージされたリポジトリの様子
亜琉美

story/#16ブランチがmasterブランチへマージされているのがグラフで分かります。また、#16のチケットを見ると自動的にステータスが「終了」になっています。


まいん

ブランチの作成とチケットの関連付け機能をうまく使えば、以下のようにチケットをあまり意識することなくGitを使って開発作業を進めていけるよ。


  1. 作業の前にブランチ作成
  2. 作業→コミット、作業→コミット
  3. レビュー・テスト
  4. masterブランチへマージ
ぷりん

コミットを中心として開発するなら、「コミット駆動開発」って呼んでいい?


亜琉美

却下します。呼び名が増えると混乱します。


ぷりん

ひ、ひどいよ……。そんな冷たくいわなくたって……(T_T)。


まいん

ちなみに、ALMiniumのブランチとチケットの連携機能は筆者が開発している「Redmine Git Branch Hook」プラグインを利用しているみたいね。元のRedmineでもRedmine Git Branch Hookプラグインを利用すると、ブランチとチケットの関連付けできるようになるよ。


ぷりん

えっ?筆者ってプラグインなんて作れたの?こんな駄文しか書いてないのかと思ってた。これの開発もレビューしてくれる人がいないのかな……(涙)。


亜琉美

この機能はGitHubで実装されている「プルリクエスト」と呼ばれる機能にインスパイアされたようです。開発者がブランチで開発を行い、ブランチの変更をレビューした人がマージする、という考え方の部分は、ほぼそのままですね。


ストーリー(プロダクトバックログ)とレビュー

ぷりん

ところで、この連載ってスクラムの話だったと思うけど、レビューしてからチケットを閉じるという話が出てたけど、スクラムでコードをレビューするタイミングってどうすればいいの?


まいん

ストーリーごとにブランチを切って開発する場合、ストーリーに関するすべての作業(例えば、下の例では検討、実装、テスト)が終わったときが1つの目安になるかな。具体的には、“かんばん”が次のようにストーリーのタスクがすべて終了になったときね。


図13 ストーリーをマージするタイミングの例
図13 ストーリーをマージするタイミングの例
亜琉美

“かんばん”のステータスで「レビュー」があるので、「実装」のタスクがレビュー状態になったときにコードレビューを行を行ってマージする、というやり方もできます。


まいん

どれがいいかは人それぞれだと思うから、やりやすい方法でやるのがいいわね。流行としては、他の開発者に迷惑を掛けないように「テストしてからマージ」というのがいいみたいよ。


涙のチケット駆動開発の鍵ッ!?

亜琉美

今回はRedmineにおけるGitのコミットの使い方を見ていきました。コミット・ブランチとチケットをうまく使うことにより、何のために変更したのか、○○を実現するために、どこを変更したのか、ということが分かりやすくなります。


まいん

チケットとコミット・ブランチの対応付けは作業管理単位をチケットで行うチケット駆動開発にとってもキーとなる機能ね。Redmine Backlogsの“かんばん”でタスクを管理できるようになったら、ぜひコミットとの連携も試してみてね。


ぷりん

なんだか今日は、筆者のエピソードや亜琉美ちゃんの冷たいつっこみで涙を流してばっかりだった気がするな……(T_T)。でも、気を取り直して……。



ホームワーク!
ぷりん

今日の宿題を出すよー。私もやってみるから、みんなも一緒にがんばろーねッ!


問1

 適当なチケットを作成し、コミット時にメッセージに「(refs #チケット番号)」を含めコミットをチケットに関連付けてみましょう。チケットと関連付けるには、コミットを共有リポジトリへプッシュする必要があるので注意してください。

問2

 問1のrefsをclosesキーワードに変更し、チケットを閉じてみましょう。

問3

 別のチケットを作成し、「story/#チケットID」という名前のブランチを作成しブランチにコミット後、プッシュしてみましょう。チケット(ストーリー)を確認し、ブランチへのコミットが対応付いているかどうか確認してください。

問4

 問3のブランチをmasterブランチへマージし、チケットがクローズ状態になっていることを確認しましょう。

本稿の図版について

 本稿の図版は京風子(Kyoko)氏作成の「あんずもじ」フォントを利用しています。

著者紹介

文:認定スクラムマスター 岡本隆史

イラスト:本橋ゆうこ



Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る