Mercurial

2015/06/11

GitHubはオープンソースのプロセスを標準化した

「GitHubはオープンソースのプロセスを標準化した」記事の感想をメモ。

【参考】
GitHubはオープンソースのプロセスを標準化した。これからはコード開発以外にも使われていく。AWS Summit Tokyo 2015 - Publickey

akipiiさんはTwitterを使っています: "そうなのか?RT @koyhoge: Redmine にパッチを投げる不便さを解決するところから GitHub は生まれたのか。 #awssummit #key02"

akipiiさんはTwitterを使っています: "ふむー。RT @toshihirock: Github以前、svnにもアクセスできないからソースコードをダウンロードして、パッチ作ってみたいな大変。そしてやりとりをredmineで。そして個人的な功績は残らない。しんどい #AWSSummit"

akipiiさんはTwitterを使っています: "同感。RT @mesaka2009: 昨日のGithubの人の講演。たった10年でこれだけ変わった。と言う事の一つに、Redmineでやり取りしていたのがGithubになった。とあったけど、日本の企業にはまだまだRedmineは現役だぞい!"

GitHubの偉大さは、Publickeyの記事の通り、オープンソースの開発プロセスの事実上のデファクトスダンダートになったことだろう。
オープンソースで何かしらの貢献をしたい開発者は、GitHubにアカウントを持ち、フォークしてパッチを送る方法をプルリクするやり方を学ぶ必要がある。
GitHubにないソースの保守は、とても面倒だ。

上記の記事の通り、以前は、diffコマンドを作り、patchコマンドでtrunkにDiffパッチを取り込むやり方を行なっていた。
そして、メーリングリストでダラダラとやり取りしていた。

あるいは、ReviewBoardというコードレビューWebシステムがあったが、その機能は、Subversionのtrunkに対し、patchを添付するとWeb上でDiffが表示されて、そのDiffを中心にコミッタと開発者がコメントし合うやり方だった。

ReviewBoardでプレコミットレビュー: プログラマの思索

ReviewBoardを使うプロセスとは?: プログラマの思索

でも、GitHubのおかげで、全てはプルリク駆動の開発プロセスで標準化された。
好きなだけフォークして、ブランチを作り、マージ依頼をプルリクすればいいだけ。
このやり方で、より高速な開発が可能になったし、ソースに関するすべての作業がWeb上で公開されているので、開発プロセスの透明化にもつながった。

但し、Redmineを過去の遺物で紹介されたのはちょっと違和感があった。
RedmineとGitHubは、利用シーンも使い方も目的も全く違う。

GitHubはソース中心のプルリク駆動開発であり、Issue管理の機能は正直弱い。
チケット集計機能もないし、Issueにコメントをやり取りするのが中心で、ステータス管理もシンプル。
チケットはフロー型。
チケットは完了したら捨てる。
チケット管理の機能はそもそも不十分だし、それでいいと割り切っている。

逆に、Redmineはチケット管理機能がすごく充実している。
Redmineのチケットはストック型。
チケットに作業や課題、障害などの情報を記録し、後で検索できるように蓄積していくべきもの。
Redmineは「チケット駆動開発」が本来の使い方だと僕は思う。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

つまり、RedmineとGitHubの違いは、チケット駆動開発とプルリク駆動開発の違いであり、その優劣を言い合っても意味が無い。
使う用途が全く違うのだから、利用シーンに応じて使い分ければいい。

| | コメント (0)

2013/02/09

「反復型ソフトウェア開発」はソフトウェア工学の良書

実践反復型ソフトウェア開発」を読んでみたら、構成管理・ビルド管理・障害管理の方法や概念、用語がうまく整理されて説明されていて、とても分かりやすかった。
僕もこんな本を書きたかった。
ラフなメモ書き。

僕がRedmineによるチケット駆動開発を見つけて、ハマった理由の一つは、ソフトウェア開発特有の技術や概念がここにある、と直感したから。
バージョン管理やビルド管理、障害管理は、ソフトウェアに関わる仕事をしている人ならば、必ずかじっている。
でも、実は、バージョン管理やビルド管理、障害管理について、正式な説明も勉強も受けたことがなく、現場で失敗を繰り返してようやく身に付けた技術が多いのではないだろうか?

ソフトウェア開発は、プログラムを書けばそれで終わりではない。
チームでソフトウェアを開発する場合、複数人の作業が衝突しないようにバージョン管理が必要だ。
クライアントアプリを配布したり、Webサーバーへモジュールをりりーするには、ソースからビルドしてデプロイないしインストーラーを作成するビルド手順を自動化ないし定形作業化した方がいい。
テスト中やリリース後に発生した障害は、BTSやITSで管理して、ソフトウェアの品質向上に役立てるようにする。

それらの作業はとても地味だけれども、プロジェクトの成功のための基盤となるものだ。
技術者で生きていく限り、ソフトウェア開発の基盤となる構成管理、ビルド管理、障害管理は常に最新の情報を追いかけるべきだ。
何故なら、それらの技術は時代とともにどんどんパワフルになっているから。
そして、それらの開発基盤は最終的には開発プロセスへ取り込まれる。
開発プロセスの品質を向上させるには、開発基盤の効率化も欠かせない。

ソースをバージョン管理するのは当たり前だが、ブランチをそれぞれの目的に応じて作って、管理しているか?
マージ作業を手作業でやって失敗していないか?
GitやMercurialのような最新のSCMを使って、メインラインとトピックブランチを使い分けているか?

複数チームで開発している場合、いきなりメインラインにコミットやマージするのではなく、段階的統合ブランチを使って、品質が安定したと分かってからメインラインに入れるようにしているか?

保守ブランチとして、リリースブランチ、リリース準備ブランチ、ユーザブランチをそれぞれの用途に応じて使い分けているか?
作業ブランチとして、フィーチャブランチ、トピックブランチ、バグフィックスブランチ、リファクタブランチなどを使い分けているか?

最新版でセキュリティパッチを当てた時、既にリリース済みの古いバージョンへパッチを当てるバックポートを意識して使っているか?

ブランチにおける指定された範囲内のリビジョンをまとめてメインラインへポートするバルクポートと、必要なリビジョンだけを選んでポートするチェリーピックポートを使い分けているか?
(これは、Gitのcherry-pickコマンドと同じ)

ベースとなるソースを更新するリベースを使っているか?

2個のブランチ間でポートを繰り返す双方向マージを行う場合、マージトラッキング機能が強力なSCMを使ってマージ機能を自動化できるようにしているか?

実践反復型ソフトウェア開発」で興味深い箇所は、構成管理や障害管理の章で、「チケット駆動開発」という単語は出ていないけれども、チケット駆動開発に関わる概念が出ていること。
コミットフック、障害管理票とソースのリビジョンの紐づけは、No Ticket, No Commitにつながる。
BTSを障害だけでなくToDoリストへ拡張することは、Ticket Firstにつながる。
障害管理票がなければ作業を開始しないことは、No Ticket, No Workにつながる。
BTSチケットがソフトウェアかんばん、そして工場内で使われる仕掛けかんばんに似ていることは、リーンソフトウェア開発につながる。

この辺りはもっと整理してみたいと思う。

| | コメント (0)

2013/01/12

Mercurialに取り込まれたコミュニティ由来の機能一覧

入門Mercurial」の著者の藤原さんが、Mercurialに取り込まれたコミュニティ由来の機能一覧を公開されていたので、リンクをメモ。

【元ネタ】
Mercurial に関するコミュニティ由来の成果(2012年版) - 彷徨えるフジワラ

とても素晴らしいなあと思う。

| | コメント (0)

2012/12/07

WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg

以前、WordやExcelから直接SVNにコミットできるアドオンを紹介したが、Mercurial版ができたようだ。
とても嬉しい。

【元ネタ】
Introduction_ja - msofficesvn - Microsoft Office (Excel, Word, PowerPoint) add-ins that assist document version control - Google Project Hosting

WordやExcelから直接SVNにコミットできるアドオンmsofficesvn: プログラマの思索

Excel Word の文書管理に Mercurial? - MAJ1MAの日記

IntroductionJ - msofficehg - Microsoft Office (Excel, Word, PowerPoint) add-ins that assist document version control with TortoiseHg - Google Project Hosting

msofficehg - Microsoft Office (Excel, Word, PowerPoint) add-ins that assist document version control with TortoiseHg - Google Project Hosting

(引用開始)
Microsoft Officeのアドインとして機能し、ワード、エクセル、パワーポイントのリボンインターフェースからバージョン管理ソフトであるTortoiseHgのコマンドを実行することができます。
TortoiseHgは、ソフトウェアのソースコードのバージョン管理をするのに定評のあるソフトウェアですが、文書ファイルのバージョン管理にも便利に利用できます。 マイクロソフト オフィスファイルの文書管理が必要な場合、TortoiseHgの利用をご検討されることをお勧めします。
(引用終了)

MercurialでExcelやWordを使う利点は、ローカルPC上でプライベートブランチで履歴管理できること。
例えば、Bitbucketにプライベートリポジトリを作っておき、そこからローカルPCへクローンしてコミットすれば常に履歴管理できる。
また、Bitbucketと常時同期しておけば、PCが壊れてもサーバー上にバックアップがあるからいつでも復元できる。

提案資料、報告資料、課題一覧など、マネージャや営業マンはOffice文書を保守する場面が多い。
Office文書もプログラムと同じように、少しずつ書いては推敲していくのが普通だ。
だから、Mercurialのような強力なバージョン管理ツールとセットで運用する方が、作業効率が良くなるだろうと思う。
上記のアドオンを入れれば、上部のインターフェイスから選択できるので便利。


| | コメント (0)

2012/11/23

RedmineでSubversion リポジトリ表示を高速化する方法

RedmineでSubversion リポジトリ表示を高速化する方法について、丸山さんが回答されていたのでメモ。

【元ネタ】
Subversion リポジトリ表示に時間がかかる - Google グループ

小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog

バージョン管理システムとの連携 | Redmine.JP

メーリングリストで以下の問題を提起されている。

(引用開始)
実プロジェクトで問題が起きたので、相談させてください。

・環境
 Redmine 1.3.3 / Ruby 1.8.7

・設定
 管理→設定画面のリポジトリタグで「コミットを自動取得する」はOffになっています

・症状
 Subversionのリポジトリを表示させると、時間がかかる
 →270程度のリビジョンを含むリポジトリで、およそ6秒かかる(100 ms程度の誤差で再現性あり、何度開いても状況変わらない)
 →この6秒の間, topコマンドで監視するとsvnコマンドがCPU1コア分を持って行っている

 現在、SubversionのサーバとRedmineのサーバは物理的に別マシン

・なんとかしたい
 Subversionのリポジトリ表示に時間がかからないようにしたい

svnコマンドが動いていることから、「設定」にあるコミットの自動取得Offの設定がうまくいっていないのでは?と思います。
次に調査できそうな場所など、ご教示いただければ幸いです。
(引用終了)

この現象は、既存のSVNリポジトリが例えば1万リビジョン以上もあり新規プロジェクトに登録すると、タイムアウトエラーになってしまう場合でも現れる。
原因と対策は、丸山さんが説明してくれている。

(引用開始)
リポジトリツリーの表示に"svn ls"を、リビジョン一覧の表示に"svn log"を叩いています。
つまり、1つの画面の表示にsvnコマンドを2回叩いています。
おそらくSubversionのパスが"svn://"か"http://"に指定されていると思います。
"file://"に変えるとかなり早くなると思います。
(引用終了)

原因は、Web経由でSVNリビジョン情報をごっそり取得しようとするので、HTTPレスポンスが所定時間内にリターンせず、タイムアウトになるから。
対策としては、Redmineと同じサーバー上にSVNリポジトリを同期しておき、そこから接続するようにする。

SVNならsvnsyncで別サーバーにあるSVNリポジトリとリアルタイムで同期するようにすればいい。
GitやMercurialなら、別サーバーのmasterブランチをクローンした後に定期的にpullすればいい。

SVNの既存リポジトリが大きすぎて、新規プロジェクトへ既存SVNリポジトリに登録するとタイムアウトしてしまう場合は、fetch_changesetsスクリプトをバックグラウンドで実施する方法で解決できると@g_maedaさんから聞いた。

ruby script/runner "Repository.fetch_changesets" -e production

リポジトリ | Redmine.JP

この方法の仕組みは、既存のSVNリポジトリからRedmineのDBへバッチ処理で定期的に取り込む処理になる。
つまり、Jenkinsのような高機能化したビルド管理ツールを使って、定期的にSVNリポジトリと同期するバッチジョブを走らせればいい。

Redmineを業務システム化するアイデア~メトリクス集計の本質は集計バッチ処理: プログラマの思索

Redmineとバージョン管理リポジトリの連携機能は、チケット駆動開発の発端となった「No Ticket, No Commit」に由来する運用ルールと密接に関係するため、この機能が使えなくなるとチケット駆動の威力が半減する。
チケットで成果物の変更管理をするだけでなく、トレーサビリティという効果も現れる重要な機能だからだ。

先日のRxtStudyでも、@akahane92さんがRedmineの性能改善に関する発表でも、上記に関連する内容を説明されていた。
もう一度再認識してみる。

| | コメント (0)

2012/11/10

【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ベータ版)」 #47redmine

本日行われた第4回品川Redmine勉強会の発表資料をCCアトリビューションライセンスで公開します。
スタッフの皆さん、参加者の皆さん、お疲れ様でした。

第4回shinagawa.redmine勉強会 : ATND

今僕が考えている「チケット駆動開発をパターン言語で表現できるか」という問題に対して、勉強会のお題「チケットの粒度」「チケットの完了条件」について当てはめると、どれだけ本質に迫れるか、考えた結果を話しました。
内容は完成版でないし、解法は一つではないです。
オープンディスカッションの前座として、どれだけ皆の議論を引き出せるか、という観点で話しました。

オープンディスカッションでは7チームで議論してもらった結果、白熱したチームもあれば、違う議題に行ってしまったチームもあったり、面白かったです。
この2つの質問は、チケット駆動開発を実践する時に必ず通過しなければならない問題なので、勉強会で議論できたことは有意義だったと思います。

また、丸山さんのMercurialのお話、岡本さんのGitとScrumのお話、小久保さんのBacklogsプラグインの運用例のお話もありました。
Redmine界隈では著名な人たちばかりなので、今日の講演は盛り沢山だったかな。

岡本さんと丸山さんの話では、MercurialとGitではブランチの概念が全く違うという意味が、今日の勉強会で一番大きな収穫だったと個人的に思います。
チケット駆動開発の面白さの一つは、単なるタスク管理の上手な使い方だけでなく、構成管理の上手な使い方にも言及している所なので、コミュニティでまだまだ議論できる余地があります。

小久保さんの話では、Backlogsプラグインのカスタマイズで、新規ステータスから作業中ステータスへ変更する時に実績工数を入力しなければエラーとか、別のステータスへ遷移する時にコメント入力を強制させたり、却下ステータスへ移動する時は理由なしならエラーとするなど、ワークフローに関する制御が多くありました。
従来型開発では、ワークフローの制御はリーダーの承認や判子を押すなどの作業を入れたり、Excelなどのドキュメントに書き残してメンバーに強制させる手法でしたが、このやり方では、ワークフローの制御ルールをツールの1機能へ吸収してしまうことによって、開発者が意識しなくてもいいという利点があります。

小久保さんが、ツールの機能に実装されていないルールはメンバーに強制しない、と話された内容は、ワークフローの制御という開発プロセスの業務ロジックはチケット管理ツールの1機能になっているので、メンバーは自然に厳格なルールに従って作業できる利点を意味しています。
ソフトウェア開発のベストプラクティスはツールの1機能で実装してしまえばいい、という見本のような例だと思います。

そして、岡本さんがRedmine Git Branch Hookを紹介して下さったように、チケット駆動開発の基本的なプラクティスである「No Ticket, No Commit」をトピックブランチやストーリーブランチへ適用して、チケット単位にブランチを分岐して修正する場合はチケットにリビジョンの履歴をフックスクリプトで自然に残すという「No Tikcket, No Fork」へ発展させる使い方もあります。
つまり、チケット駆動開発はその時代のツールの最新の使い方を取り入れることによって、更に進化できる余地が沢山あります。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索

今後も品川Redmine勉強会というコミュニティの場で、Redmineコミッタとユーザの間で有意義な議論を交換しながら、より良い実践技法を通じて、チケット駆動開発を日本発のソフトウェア開発技法として提唱できたらいいなと思います。

【追記】
丸山さん、岡本さんのスライドはコチラ。

Redmineのブランチ戦略

| | コメント (0)

2012/09/30

git-flowのMercurial版hgflow

git-flowのMercurial版hgflowがあると聞いたのでメモ。

【元ネタ】
hgflow - wyukawa’s blog

紹介マニアどらふと版: hgflowを試してみる

yinwm / hgflow / wiki / Home ? Bitbucket

yinwm / hgflow / wiki / UserManual ? Bitbucket

(分散)バージョン管理システムの組織化

subversionでのブランチマネジメント - TIM Labs

git-flow による構成管理とRedmineの関係: プログラマの思索

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

【1】hgflowを使うには、yinwm / hgflow / wiki / Home ? Bitbucketからhg clonwして、mercurial.iniへ

[extensions]
hgflow = /PATH/TO/hgflow.py

を追加するだけ。
yinwm / hgflow / wiki / UserManual ? Bitbucketに書いているように、hg flow initから始まり、後はgit-flowのコマンドと同じだ。

【2】(分散)バージョン管理システムの組織化の資料はとても分かりやすい。
メインラインモデルとgit-flowモデルに対し、ブランチ管理の考え方の違いをうまく説明している。

メインラインモデルでは、develop=trunk。
つまり、メインラインは開発中のコードラインであり、最新の機能がコミット済み。
そして、このtrunkからリリースすればリリースブランチ、特定目的であれば、トピックブランチやタスクブランチが分岐される。
Redmineの開発はメインラインモデルで運用されている。

/ - リポジトリ - Redmine

重要な点は、メインラインはリリース可能なコードラインとは限らないこと。

本来のメインラインの定義は、メインラインの定義: プログラマの思索に書いた通り、「最新の機能を持つ」が「リリース可能」とは限らないが、アジャイル開発を運用しているならば、事実上、メインラインは「リリース可能」なコードラインにならざるを得ないと考えている。

git-flowモデルでは、stable=trunk。
つまり、メインラインはリリース済みのコードライン又はいつでもリリース可能なコードライン。
開発者は、特定の期日までに開発するマイルストーンブランチをtrunkから派生し、ブランチ上で作業後、trunkへマージする。
masterブランチはtag専用で、リリース時に作られるだけ。

マイルストーンブランチには、序盤の開発と終盤の開発の2種類がある。
序盤は、新機能の開発であるフィーチャブランチが多いだろう。
終盤は、バグ修正のホットフィックスブランチやリリース作業を事前準備するためのリリース準備ブランチが多いだろう。

特に、git-flowないしhgflowを使うならば、ブランチはITSチケット単位に作り、story/#11などのようにチケット番号で分かるようにした方が運用しやすい。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索にも書いたが、チケット単位にブランチ管理する手法は、「No Ticket, No Commit」の拡張版を生み出す可能性を秘めていて、今後の運用で重要な役割を担うと思っている。

但し、第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索にも書いたが、git-flowモデルを採用したChiliprojectはソース管理がとても複雑化しているのに対し、メインラインモデルを採用した本家のRedmineは頻繁なバージョンアップに伴い、どんどん使いやすくなっている。
この辺りの違いについても、次回の品川Redmine勉強会で議論してみたいと思っている。

| | コメント (0)

ソフトウェア構成管理はチケット駆動開発がサポートする

もう絶版になっているが「ソフトウェア構成管理の悪夢」の一節に、ソフトウェア構成管理の基本成分が書かれていたのでメモ。

ソフトウェア構成管理に至るまでの道のり: プログラマの思索

SW構成管理とはそもそも何なのか?: プログラマの思索

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける: プログラマの思索

Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索

チケット駆動開発がもたらした新しい観点part2~トレーサビリティの拡張: プログラマの思索

Subversion・Git・Mercurialの比較: プログラマの思索

ソフトウェア構成管理の基本成分は4つある。

1・コンポーネントのバージョン管理
2・開発環境ん管理
3・ビルド管理
4・工程管理

1つ目は、ソフトウェアの各部位のライブラリのバージョン管理。
特定のLinuxディストリビューションのgccのバージョンが古い理由は、SCMの負の遺産だろう、という例がある。
90年代から始まったホスト中心の開発からクラサバ・Webへのオープン開発への移行という歴史的背景からすれば、DB・Webサーバー・プログラミング言語・フレームワークなどの各種バージョンを組み合わせて実装する時のサポートに相当するだろう。

2つ目は、開発者の環境におけるバージョン管理の実装。
本では、CVSが相当すると書かれているが、現代ならば、SubversioやGit、Mercurialが相当するだろう。

3つ目は、コンパイルとデプロイ、リリースの管理に相当する。
Cのmakeが例にあげられていたが、現代ならば、AntやMaven、rakeが相当するだろう。
この役割を担う人は、「リリースOKかNGか」を出すのがその責務になる。
今ならば、Jenkinsがその役割を自動化しているだろう。

4つ目は、要件の変更、ソース修正の変更管理、ドキュメント整備などが相当する。
これらの作業の管理のために、CMマネージャ(構成管理マネージャ)という役割を作り、CMマネージャはプロジェクト内部の交差点に立つ交通整理役を担う。
普通は、この役割は、バージョン管理ツールや開発者、QA、プロジェクトリーダーなどの各種役割に分散されているだろう。

CMマネージャは普通はライブラリアンと呼ばれる役割に相当するだろうと思う。
最終的なソフトウェア製品をリリースする役割を担うだけでなく、製品のバージョン管理や変更管理にも責任を伴う。

ソフトウェア構成管理の悪夢」が出版されたのは1999年なので、今から読むとかなり古くなっている部分もある。
特にCMマネージャ、ライブラリアンの役割は、現代ならば、おそらく消え去る役割だと思っている。

製品のバージョン管理や変更管理を支える作業を人手で行なっていた時、その役割を担う専門担当者が必要で、開発者やリーダーから情報を収集し、管理していた。
でも、今は、GitやMercurialで高度なバージョン管理が行えるし、ビルド管理はJenkinsが代用しているし、要件や仕様やソース修正の変更管理はRedmineやTracなどのプロジェクト管理ツールが代用しつつある。

つまり、チケット管理システムがCMマネージャの役割を担当することで、作業を自動化するだけでなく、その役割を透明化してしまった。

他にも、XPのトラッカーの役割はTiDDがサポートする: プログラマの思索にも書いたが、XPでも、プロジェクト内部の進捗情報を収集する役割としてトラッカーという担当者がいたけれども、その役割はチケット管理システムが吸収した。

そんなことを考えると、昔は人力作業でやるしかなかったために、プロジェクトの管理作業を複数の役割を持つ担当者に細分化してサポートさせていたが、チケット駆動開発はそれらの作業者を吸収して、少人数のチームでも効率よく開発できる環境を提供しようとしていると言える。

Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索

それによって、チケット駆動開発がアジャイル開発を更に進化させるのではないか、ソフトウェア開発組織のあるべき姿を提示できるのではないか、と直感している。

Twitter / sugimoto_kei: 昨晩の関西IT勉強宴会で、@akipii さんの話を聞いて感じたのは、チケット駆動開発というのは、マネージャの管理ワークの大部分をメンバに移管する基礎を提供することによって、「管理」という仕事の性質と分担を変革しようとする試みではないかということ。単なる自動化じゃないんだよね。

Twitter / akipii: @sugimoto_kei はい、その観点でチケット駆動開発を体系化しようとしています。ERP導入によって女性の事務員が不要になり組織構成が変わってしまうように、チケット駆動開発は単なる管理作業の自動化だけでなくソフトウェア開発組織のあるべき姿を提示できるはずと思ってます

| | コメント (0)

2012/09/22

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法

@LightningXさんが、Redmine×Gitで新しい運用方法を提唱されていたのでメモ。

【元ネタ】
Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - @IT

Redmine×Gitのハーモニーは涙のチケット駆動開発!? (2/3) - @IT

Redmine×Gitのハーモニーは涙のチケット駆動開発!? (3/3) - @IT

Gitのような分散バージョン管理の場合、No Ticket, No Commitはどのように拡張されるのか?

(引用開始)
「チケット駆動開発」(Ticket-Driven Development、TiDD) と呼ばれるチケットベースで作業を管理する手法では、このコミットとチケットの関連付けが作業を管理するうえでのキーポイントになるんだよ。例えば、ストーリーの実装やバグの修正というチケットがあった場合、その作業でどこが変更されたのか、管理できるよ。
(中略)
ブランチのチケットへの対応付けは、図のようにブランチ名に「#」とチケットIDを入れてブランチを作成するだけです。例えば、チケットID「16」のチケットへ対応付けるブランチは「story/#16」のような名前で作ります。「impl-reply-func-#16」などのブランチ名にしても大丈夫です。

$ git branch story/#16
$ git checkout story/#16

もしくは、

$ git checkout -b story/#16
(中略)
 図9と10を見ると、コミットメッセージの先頭に「refs #16」が付いていますが、これはRedmineのプラグインがコミットメッセージに自動的に関連キーワードを追加しているの。実際には、コミットメッセージには、「ブランチのコミットをチケットへの反映を実装」のようにチケット番号を含める必要はありません。
 これは、「story/#xx」というブランチ名を利用する例だけど、タスクに対応付けたい場合、「task/#xxx」、バグに対応付けたい場合「bug/#xxx」とすると、各ブランチが何の作業なのか分かって便利だよ。
(中略)
ポイントは、「git push」コマンドでプッシュが必要なところね。共有リポジトリにコミットを送信しないと、Redmine(ALMinium)側でコミットによりソースが変更されたことが分からないから、チケットと関連付けされるのは「プッシュした後」になるの。

$ git push -u origin story/#16
(初めてブランチをプッシュする場合)
$ git push
(2回目以降)
(中略)
「ブランチをマージしてからチケットを閉じる」と説明しましたが、「Redmine Git Branch Hook」(後述)というマージ時に自動的にチケットをクローズするプラグインがあります。例えば、先ほどコミットしていったstory/#16ブランチを次のようにしてmasterブランチへマージします。

$ git checkout master
(masterブランチへ移動)
$ git merge --no-ff story/#16
(masterブランチへstory/#16ブランチをmasterブランチへマージ)
$ git push
(引用終了)

上記の使い方を見ると、以下でまとめられる。

(1)チケット単位にブランチをoriginからフォークする
git branch story/#16

(2)フォークしたブランチ上の修正コミットは、Redmineのリポジトリブラウザへ自動でpost-commit-hookされる

(3)originへブランチからpushする
git push -u origin story/#16
または
git push

(4)ブランチの修正を一括マージして、チケットも同時にCloseする
git checkout master
git merge --no-ff story/#16
git push

僕が以前Subversionを使っていた時、Redmineの複数プロジェクト機能を使って、プロジェクトとブランチと同期させることによって、ブランチの変更履歴を管理しやすいようにしていた。
つまり、リリースブランチを作るたびにRedmineプロジェクトが作られて、次のリリースでプロジェクトもリリースブランチも廃止される運用を行なっていた。
しかし、この運用は、リリースするたびにプロジェクトが増えてしまい、逆に管理しづらくなる弱点があった。

Redmine1.4以降では、1プロジェクトで複数リポジトリを登録できるため、リリースブランチやトピックブランチ、フィーチャブランチなどは1プロジェクトにまとめた方がチケット管理しやすくなる。
上記のように、分散バージョン管理とITSを連携する場合、ブランチの生存期間をプロジェクトではなく、チケットの生存期間に合わせる方が運用しやすいだろう。

何故なら、GitやMercurialでは、複数のブランチが常に併存するのは当たり前であり、それらブランチの寿命は短いのが普通なので、ITSプロジェクトのように生存期間の長い機能よりもチケットの方が管理しやすくなるだろうと思う。
その利点は、トピックブランチのライフサイクルをチケットの生存期間と一致させることによって、ソース修正の変更履歴を記録しやすくできるからだ。

つまり、「チケット無しでフォークやプルリクエストは許さない」というチケット駆動の新しい運用方法と言えると思う。
「No Ticket, No Branch」という運用方法と呼ばれるかもしれない。

また、「この機能はGitHubで実装されている「プルリクエスト」と呼ばれる機能にインスパイアされたようです。開発者がブランチで開発を行い、ブランチの変更をレビューした人がマージする、という考え方の部分は、ほぼそのままですね。」という指摘も興味深い。
GitHubのプルリクエスト機能がとても素晴らしい理由の一つは、単なるマージ作業依頼だけでなく、パッチのコードレビューをオンライン上で実現できるようにしたからだと思う。
コミッタはプルリクエストを受け取る時点で、パッチの差分を必ずチェックする作業が自然に生まれるからだ。

GitやMercurialのフォークやプルリクエストは、単なるブランチ管理やマージ作業だけでなく、コードレビューという非同期ペアプログラミングを実現する重要な運用を生んでいることにも注意したい。

| | コメント (0)

2012/09/12

チケット駆動開発が進むべき道part5~Agile開発プロセスとして再構築する

チケット駆動開発本の感想を読んで、チケット駆動開発が進むべき道について考えたことをメモ。

【1】Twitter / SugiTK: Redmineの使い方なのかチケットの運用の仕方なのかというのも微妙な立ち位置になってしまってるかなと。例に挙げられていたERPの話と同様に、ツールをRedmineにすると決めたならそれに合わせて業務も変わるわけで、Redmineならこうしますというほうが。それは前著ですか…

Twitter / SugiTK: アンチパターン集は読みやすかったです。パターンテンプレートに沿っていたからでしょうか。既存のいい見本があると見やすくなるということはあるのかもしれませんね。

Twitter / SugiTK: 12章。「テーラリング」という単語はあまり一般的ではないのではなかろうかと。新卒のときの研修でPMBOKやQCのプロセスについてテーラリングするというのを部長から教わったのをなぜかよく覚えていますが、その後10年以上聞いたことがありません。

Twitter / SugiTK: 読後感としては「う?ん」と悩んでしまいました。本を書くのはやはり難しいんだなぁと。わたしは雑誌記事を10回程度しか経験がないですが、相当に大変でした。知っていることを全て表現できるわけでもなく、書いたことが全部伝わるわけでもない。難しいです。

【2】チケット駆動開発の感想 - ブクログ

宝探しが必要な本です。自分が深く関わったことがある部分に対しては、この本に書かれているノウハウがとスッっと入ってきてとても参考になったのですが、経験が浅い部分については何がポイントなのか、、、話が散逸していてよく分かりませんでした。
「プロジェクト管理の原理原則」、「チケット駆動開発により改善が進むポイント」、「実践のノウハウと実例(ツール)」と大きく3部に分けて整理し直すだけでものすごく良い本になるのではと思います。
手元に置いておいて、プロジェクトマネジメントで悩んだ時に、部分的に読み返すという使い方が良いかもしれません。

【3】Amazon.co.jp: チケット駆動開発
(引用開始)
導入部はよく書けていて期待が膨らんだが、完全に裏切られた。厳しいレビューとなりますがご容赦。

まるで思いつきを思いついた順に並べたような本だ。これではひとつの開発方法論という以前に、一冊の技術書として成立していないと思う。
全体がうまく構成されていないし、各論も要点が全く整理されておらず、何が言いたいのか不明な部分が多い。
技術的な誤りも多い。著者らの前著も突っ込み所満載といった印象だったが、この本はそれ以上にひどい。
同じことを何度も繰り返しつつ、ほかの文章を適当に引用してはいい加減な論評を繰り返し、脈絡なく「チケット駆動はこれを改善するでしょう」などと結ぶばかり。
自分が開発するシステムの仕様書がこんなふうに書かれていたら、私は激怒すると思う。

第一、BTSとSCMが連携する開発支援ツールはMicrosoftやPerforce、Rationalなどがずっと以前からリリースしているしこの本を読む限り、「チケット駆動」というのがBTS/ITSの新しい活用法を編み出したとは見えない。
これだけ厚い本なのに、「BTS/ITSを活用しましょう」という以上のメッセージは読み取れなかった。

著者らは、「チケット駆動」というわかりやすい言葉で、日本のソフトウェア業界にBTS/ITSの導入を啓蒙した。その大きな貢献は否定しない。
(そんなところから啓蒙しなくちゃいけない日本の業界もどうかとは思うが)
しかし、この本はあまりに技術書としての体裁を欠いている。ブログじゃないんだから。もう少し、まともな本に仕上げてほしかった。
これでは「チケット駆動」とは名前負けの看板倒れ、中身は何もないと言われても仕方がないだろう。
チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか。

次回は、要点だけをコンパクトにまとめた、現場でリファレンスとして使える本を期待したい。(日本発の開発方法論として、まだ期待してるんですよ。)
せめて、目次を見たらどこに何が書いてあるのかわかる程度には、内容を整理すべきだろう。
業界からの「チケット駆動」に対する期待と、著者らの業界に対する影響力の大きさを考慮して-1点。
(引用終了)

(引用開始)
障害管理、構成管理、アジャイル、SCMなどなど、幅広い内容が分散して書かれているため、チケット駆動開発の本質的なところ(この本が伝えたいこと)がよくわからない。

チケット駆動開発の基本のところで説明している内容を、ブレークダウンしていくつかのパターンに分類していってくれたら良かったのにと思います。
チケット駆動開発によってアジャイルが分かったとあったので、書籍もアジャイルにリファクタリングしながらつくられたのかと思ったのですが、現状だと寄せ集め感がすごくあるので、個々ではよいことが書いてある箇所はあっても、全体の読後感として、自分の現場でのアプローチに直結しない感じがしちゃう。勿体無い。
(引用終了)

【3】「チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか」という指摘に対しては、「チケット駆動開発」では、6.2節「チケット駆動開発はプラクティス?」の所で既に回答されています。

(引用開始)
チケット駆動開発をどう定義するか、それは難しい問題ですが、必ずしも解決しなくても構わない問題だと思います。できればそのままに広く情報交換して、それぞれのプロジェクトにふさわしい形でチケット駆動開発が実践できるようになればと思っています。
(引用終了)

でも、上記の回答では満足できず、チケット駆動開発の価値・原則・プラクティスを体系化して欲しいという要望に賛同する読者が多いという感想を持ちました。

また、「チケット駆動開発でアジャイルが分かった」と「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の導入部で著者が書いたにもかかわらず、「現状だと寄せ集め感がすごくある」という指摘がありました。

自分としては、前作でチケット駆動によるアジャイル開発技法はほとんど書いたと思っていて、今作では、チケット駆動が障害管理から生まれたが故にその性質が本来のTiDDであることを説明しました。
そして、アジャイル開発に限らず、色んな可能性があることを言いたくて、チケット駆動開発のバリエーションとテーラリングガイドについて色々書きました。
しかしながら、逆に「チケット駆動開発の本質的なところ」が読み取りにくくなったようです。

上記の感想を読んで、「チケット駆動開発でアジャイルが分かった」という著者の体験が体系化されてないために読みにくく、テーラリングガイドよりもチケット駆動開発をアジャイル開発の文脈で体系化して欲しいという要望があるように受け取りました。
確かにその部分はきちんと書けていない部分だと思っています。

また、「Redmineによるタスクマネジメント実践技法」を第5刷まで更新しながら思ったことは、かなり細かな部分まで著者の意図を読み取ろうとしている人が多いことです。
誤字脱字だけでなく、流れからしてこの用語やアクティビティ図は使い方がおかしい、という指摘を台湾の読者から受け取った時もありました。

上記のAmazon感想の仙川さんも、2冊共にすぐに購読して感想をアップしてくれています。
感想の評価は厳しいけれども、きちんと読んでみると、本の内容をかなり詳細な部分まで読んで理解して指摘しているのが分かりました。
(チケット駆動開発に期待して、本の評価を落とすのは変ですが(笑))

【4】「チケット駆動開発をアジャイル開発の文脈で体系化した」場合、どんな方針で考えるべきか?
今は以下の方針を考えている。

一つ目は、チケット駆動開発からツールの説明をなくすこと。
チケット駆動開発を開発プロセスとして体系化する場合、ツールは不要だし、逆に邪魔になる。
運用フローを抽象的に取り出して、フレームワークとして明確に定義してみること。

2つ目は、チケット駆動開発をアジャイル開発の文脈で、価値・原則・プラクティスでフレームワーク化できるか試みること。
価値とは「何が望ましく何がふさわしくないのかという根拠や基準」。つまり価値観。
チケット駆動開発の文脈では、チケット管理の判断基準に相当する。
チケットの取捨選択で、何を基準にして、チケットを登録し、完了しているのか?

原則とは、ドメイン固有の不変な指針。価値とプラクティスをつなぐもの。
プラクティスは、経験に基づいて定義された実践方針。パターン言語を参考にして、プラクティスを「どんな状況(Context)でどんな問題(Problem)に対してどんな解決策(Solution)が有効なのか」を明確にする。
フレームワークは、道具・役割・プロセスの3つの観点。チケット駆動開発を実行するための体制や手続きに相当する。

これらの観点でチケット駆動開発を体系化し、明確にする。

3つ目は、チケット駆動からどんなアジャイルな効果が出てくるのか、そしてアジャイルになる原因をフレームワークから導き出せるかを試みること。
今考えている方針の前提条件は、基本的には、WF型開発などアジャイル開発でない開発プロセスは対象外であり、ソフトウェア開発以外のタスク管理は除く。
つまり、アジャイル開発へ適用したチケット駆動開発について考える。

しかし、これだけ「チケット駆動開発」という概念が広く普及した周囲を見ると、チケット駆動開発の導入によってアジャイルな要素を取り入れたいという動機が多い。
だからこそ、従来型のWF型開発にチケット駆動を導入して、アジャイルな特徴という利点を部分適用したいという考え方を持つ人が多く、注目されているのだろう。

チケット駆動開発の適用範囲: プログラマの思索

チケット駆動開発を開発プロセスとして体系化した場合、何故アジャイルな効果が出てくるのか、その原因を探ってみたい。

4つ目は、XPやScrumなどの他のアジャイル開発と似ている部分と異なる部分を明確に切り分けて、チケット駆動開発を特徴づけること。
そもそも、XPもScrumもFDDも、チケット駆動ではない。
チケットという概念すらない。
あくまでも、チケットをタスクカードのように扱うことで、アジャイルな要素が出てくる特徴はあるが、アジャイルな要素はそれだけではない。
逆に、他のアジャイル開発プロセスにはなく、チケット駆動だけに特有の特徴もあるはず。
その部分を明確に切り分けてみたい。

これらの方針で、チケット駆動開発をアジャイル開発プロセスとして体系化した場合、どんな特徴が出てくるのか見てみたい。

【5】2008年にチケット駆動開発をアジャイル開発へ適用した事例を発表してずっと経つけれど、著者が想像するよりも速いペースで、世間ではチケット駆動開発の概念が進化しているように思う。

例えば、PivotalTrackerならば、よりアジャイルなチケット管理がやりやすい。
僕も実際に使ってみて、その良さは何となく分かった。
「No Tikcet, No Commit」がなくても、十分にアジャイルな特徴がある。

例えば、GitやMercurialとRedmineを連携した使い方は、著者の想像以上に発展している。
そもそも「No Tikcet, No Commit」の運用ルールは、Trac+Subversionの環境で生まれたからこそ、逆に、GitやMercurialでは、その運用ルールが古くなっている部分がある。
プライベートブランチまで「No Tikcet, No Commit」を適用するのは、開発速度を逆に落とす。

本当は、分散バージョン管理に関する使い方、考え方も「チケット駆動開発」本に書きたかったが、まだ他人に説明できるほど自分は理解できていないのであきらめた。
特に、分散バージョン管理とチケット管理の連携方法は、今後一番可能性がある分野だ。
そして、たくさんの人達が試行錯誤しながら、よりよい使い方を探している。
その使い方、考え方も綺麗に体系化してみたい。

色々考えてみる。

| | コメント (0)

より以前の記事一覧