読者です 読者をやめる 読者になる 読者になる

kondoumh のブログ

- とあるソフトウェアエンジニアのめったに更新されないブログ -

Redmine (3.1.0-0) から VisualSVN のリポジトリに接続

ITS

2015年8月18日現在、Stackoverflow 日本語版では Trac に関する質問0件、Redmine に関する質問16件。Qiita では Trac に関する投稿 98 件に対し Redmine に関する投稿は 487 件。つまり国内では Redmine が圧勝のようです。

ということで、今の開発現場では ITS として Redmine を採用することにしました。さようなら Trac ...

運用環境は、Windows Server 2012 R2 です。Windows Server 2008 と比べると格段にセキュリティに厳しくなっており、セットアップが面倒くさいという印象があります。> 2012 R2

bitnami から、Windowsインストーラーをダウンロード。使用する VCSSubversion ですが この際 Git とかも全部入りでインストールしました。

無事インストールが完了し、プロジェクトの作成とかユーザーの追加とかは滞りなくできたのですが、プロジェクトで使用することになっている既存の SVN リポジトリに繋ごうとすると

リポジトリにエントリ/リビジョンが存在しません

というエラーがでてしまいます。ログを見ると 404 で リポジトリ情報が取得できていません。どうやら SVN サーバーでは VisualSVN というのを使っているようです。VisualSVN 寡聞にして知りませんでした。リポジトリSSL/TLS で自己証明書により公開されており Redmine を導入した Windows Server 側で証明書の信用ではじかれているようです。

ぐぐるsubversion_adapter.rb の修正が必要という FAQ にヒットしました。

¥¥apps¥redmine¥htdocs¥lib¥redmine¥scm¥adapters¥subversion_adapter.rb

を開き、以下のように修正。

修正前
   str << " --no-auth-cache --non-interactive"
修正後
   str << " --trust-server-cert --no-auth-cache --non-interactive"

しかしこれだけでは、繋がりませんでした。VisualSVN サーバーのレジストリ変えたり、HTTPS 諦めて、HTTP で繋ぐように VisualSVN 側の設定変更するという記事が多かったのですが、今回は SVN サーバーに変更を加えるわけにはいきません。そこで単純に VisualSVN の自己証明書を RedmineWindows Server 2012 R2 にインストールしてみたところあっさりとリポジトリの内容を取得できました。

証明書のインポートウィザードで簡単にインストールできました。

今回、Git もインストールしておいたので、MinGW 環境が使えて、 tail -f でログ見たり、VimRuby スクリプトファイルを書き換えたりが簡単にできて助かりました。SVN オンリーの時でもインストールしておいて損はないです。

f:id:kondoumh:20160410130914p:plain

Trac 不定期通信5 シンプルさを維持する

ITS

TracRedmine のような ITS も一般的な業務アプリケーションと捉えると、開発という業務にマッチした入力画面を定義し、ユーザーである開発者にデータをエントリーしてもらうものです。例えば販売システムの受注データに相当するのが チケットと考えればいいでしょう。

チケットのクエリーで作られる各種レポートは、開発業務の状況を把握し意思決定に用いるための帳票です。正確なレポートを得るためには、入力項目を開発者が使いやすいように設定して精度の高い情報を登録してもらうことが重要です。

どのような入力項目が相応しいかは、開発チームの志向性やプロジェクトの状況によってかなり異なるというのが実際のところです。同じ業種の業務アプリケーションでも企業によって入力画面の仕様が異なるのと同じです。また、チケットの状態遷移は、開発の業務フローを反映しています。これもまたチームやプロジェクト事情で決まります。

さて、Trac はもともと(紙やスプレッドシートで Issue 管理するような)古びたやり方で開発をしているチームに最低限の支援をするという目的の元に開発されました。素の状態でも開発にまつわる問題の追跡には十分役立つだろうという入力項目とチケットフローが備わっています。逆に言うと、Trac で標準的に提供されているレベルの管理を実施していないプロジェクトは危険な道を突き進んでいると言えるでしょう。

ITS を導入する前に、その設計思想や想定している開発フローなどと現状を比較して見るのがよいでしょう。業務パッケージを導入する際、自社の業務との Fit/Gap を分析して評価するのと同じですね。自チームのやり方(自社業務のやり方) をパッケージに合わせるのか、パッケージをカスタマイズするのか。 導入までにユーザー検証を経て、既存のやり方を調整して・・・と真面目に考えるとかなり手間暇です(まあ、ITS は所詮ツールなのでそこまで大変じゃないですが)。

だからチケットにあれもこれも入れようとしてカスタムフィールドを追加しまくったり、Issue 解決までに多段階の承認ステータスを作ったりして頑張ろうとすると残念な感じになることが多いです。エントリーする開発者の負担ばかりかかってタイムリーに情報が登録されなくなり、プロジェクトの状況把握を行えなくなって行きます。
人間は自覚しているより遙かに怠惰な生き物です。シンプルこそが継続性の源泉です。そして継続性はプロジェクト成功の必要条件です。

Trac 標準の項目だって思い切って捨ててしまってもよい場合があります。優先度の調整とかイテレーション開始時の計画でやってしまえば、チケットの優先度がわりとどうでもよくなったりします。不要なフィールドであればデータを消してしまいましょう。Trac では優先度でもコンポーネントでも、データの入っていない項目は表示されなくなります。用途不明のフィールドなどノイズでしかありません。分かりやすさを第一義にしましょう。

シンプルさを保つには用途に応じて Trac プロジェクトを変えるようにするのがよいでしょう。多目的な用途には Trac はシンプルすぎます。Trac プロジェクトを跨るチケットは InterTrac リンク機能で関連付けることが可能です。機能追加・仕様変更管理用やバグ管理用などプロジェクト局面に応じて適宜追加して行くと良いでしょう。

f:id:kondoumh:20160410113556p:plain

Trac 不定期通信4 TicketQuery 記法を活用する

ITS

久々の Trac 本ネタです。

Trac のレポート機能というと、カスタムレポートやカスタムクエリで作るものと思っている人が多いと思います。確かに色々な用途でレポートを作り公開することは有効ですが、作りっぱなしで活用されないことも多いです。開発真っ最中のチームメンバーがわざわざレポートを見に来てくれることを期待するのも望み薄だったりします。


レポートではなく、よく閲覧されるWiki ページに、ページ内容にマッチしたチケットリストを埋め込んでおくのです。そうすれば閲覧の頻度が上がりチケットへの関心が高まります。 Wiki にチケット一覧を表示したい時は TicketQuery という記法が使えます。カスタムクエリで実現できるレポートはそのまま Wiki に埋め込むことができます。Wiki ページにレポートへのリンクを埋め込むという方法もありますが、やはりワンクリックが必要となり、ダイレクトなアクセスという点では劣ります。

TicketQuery を使うとリリースノートも簡単に作成出来ます。

Wiki ページにすんなりと表示されていい感じですよね。

リリースノート用の TicketQuery サンプルです。そのまんまですね。

[[TicketQuery(milestone=2.0リリース,type=機能追加|仕様変更,status=closed,resolution=対応
済,col=summary,format=table)]]

Issue をチケットで管理することで、One Fact In One Place (1つの事実は1か所) の管理ができます。さまざまな観点でのビューを用意することで開発の状況を可視化しやすくなります。システム屋だったらアタリマエのことですよね。Excel シートなんかで管理してると進捗報告用にマクロ組んだりしないといけない。バカバカしすぎ。Excel に執着するそこのあなた。Excel表計算ソフトです。問題管理ツールではありません(もちろんワードプロセッサーでもありませんよ)。

f:id:kondoumh:20160410113556p:plain

Trac 不定期通信3 TracNav を使い倒す

ITS

TracNav は古くからあるプラグインです。

プロジェクトの Wiki ページには、作業手順などチームメンバーで共有すべき内容が書かれ、どんどんページが増えていきます。有用なページでもメンバーによってはその存在を知らなかったりしますし、情報の鮮度や有効性が失われ、いつの間にか忘れ去られて埋もれてしまうものあるでしょう。でも、常にメンテナンスすべきトップレベルのページがいくつかあるはずです。TracWiki トップページはプロジェクトのポータルであり、ここに出来る限りの情報を集中させることが情報共有の第一歩です。TracNav は階層付きリストで Wiki ページヘのリンクを作りページの右側に配置できます。

ページヘのリンクの他にも以下のようなリンクがあるといいでしょう。

TracNav はトップページにかならず設置しておき、主要ページにも設置しておくとよいでしょう。スクロールしなくても見渡せる範囲に情報を集中させることが大切です。どんな人でも最初に入ってくる情報に一番注目するものです。だから知っておいて欲しい情報から並べていくのがいいです。TracNav は任意ページの箇条書き情報を指定できます。箇条書きのネストを利用して情報をカテゴライズするようにしましょう。

Trac 標準のマクロである PageOutline も ページ内の見出しで目次を生成し、TracNav のようなセクションを表示してくれますが、TracNav の表示位置と競合してしまいます。ですので、PageOutlline マクロに inlie を指定して、本文ページに埋め込むようにするとよいでしょう。

さて、Wiki に情報を集中させてもそれだけでは十分ではありません。朝会でアナウンスしたり、メールでもアナウンスしたりすることはもちろん必須です。開発者はメール読まないし朝会に遅刻してくるやつもいます。とにかく全員に染み渡らせる手間を惜しまないようにしましょう。

f:id:kondoumh:20160410113556p:plain

Trac 不定期通信2 Jenkins ビルドジョブ推移グラフで Wiki を CI ダッシュボード化

ITS

CI を健全な状態に保つことは、コードの品質維持や問題発生時の迅速な対応には欠かせません。

CI の状態をチームに通知するには、ビルドがコケた時にメールが飛ぶとか Trac のタイムラインにビルド結果を流すとかいろいろありますが、イベントドリブンになってしまうので見ない人は見ないです(スパム的に無視する)。[改訂] Trac 入門では、プロジェクトのポータル(Wiki)に Jenkins ビルドジョブの ビルドの推移 グラフを貼るという Tips を紹介してます。CI のトレンドを全員で常に監視してるような状態になって平時でも CI を意識してもらえます(それでも見ない人は見ないですが)。

今私がいるチームでは複数のモジュールを開発・保守しています。ブランチとか結合テストなどを含めるとビルドジョブの数は20個近くになるのですが、trunk で開発が進行している5,6個のビルドジョブに関しては、ビルドの推移を Wiki のトップページで一覧できるように、小さめにリサイズして並べて表示するようにしています。
チームで開発しているモジュールの CI トレンドが、ブラウザーを起動するだけで分かるため、チームメンバーの気づきが早くなり対応着手までのリードタイムが短縮されます。

モジュールのテストの数も開発が進んでいくと1000 のオーダーになるので、10個ぐらいテストがエラーになってもトレンドグラフで目立った変化が出なくなってしまいます。エラーだけを表示にしておくと、エラーが1,2個でもめちゃ派手なグラフになって、メンバーが CI のエラーに敏感になってくれる効果があります。

[[Image(http://jenkinshost/job/hogemodule/test/trend?failureOnly=true, 300px,link=http://jenkinshost/jenkins/view/hogeteam/job/hogemodule/)]]

上記の例では、hogeteam の hogemodule のビルドの推移グラフをエラーのみ表示で横幅300ピクセルで表示し、グラフのリンク先に Jenkins のビルドジョブのページを指定しています。

推移グラフではテスト前のコンパイルが失敗した場合は何も表示されないので注意が必要です。

f:id:kondoumh:20160410113556p:plain

Trac 不定期通信1 イテレーションはマイルストーン?

ITS

改訂 Trac 入門も無事発売になったことですし、不定期に Trac ネタを書いていきたいと思います。

今回は、イテレーティブ(繰り返し型)開発におけるイテレーションの扱いについて。

業務アプリ開発でも 1-2 週間という短めのサイクルでタイムボックスを区切るイテレーション(Scrum だと スプリント) を導入している現場はけっこうあるのではないでしょうか。イテレーション終わりに最終顧客に対する出荷を行わないまでも、チームの生産性や品質を短いスパンで見直し改善策を講じたりできるというメリットがあります。

ところで Tracイテレーションを扱う時ってマイルストーンで管理するでしょうか?

1チームですべての開発が完結している場合は、マイルストーンでもよいと思います。ですが、ある程度の規模のプロジェクトで複数チーム連携して開発を進める場合、チームのイテレーションとプロジェクトのマイルストーンは分けて考えた方がよいでしょう。

例えば、フレームワークや共通部品を提供するチームが先行して組織されてアプリ構築の基盤を構築し、その後アプリチームがイテレーションを開始して個別の業務アプリを構築するような場合、各チームの成果物を結合してテストやユーザー受け入れ試験に向けて出荷していくことになります。

各チームは作っているものこそ違えど、プロジェクトで設定されたイベントに向けてコードを書きテストを重ねて行きます。チームのイテレーションはタイムボックスであり、プロジェクトのマイルストーンと違ってチームの裁量が効くものです。開発対象の機能は他のチームの計画にも影響しますのでプロジェクトで決定された期日には間に合わせる必要がありますが、どのイテレーションで作業するかということは各チームの事情で決められるケースが多いはずです。

ですのでプロジェクトのマイルストーンマイルストーンで扱い、イテレーションは専用のカスタムフィールドで扱うとプロジェクト全体の観点とチーム都合の観点に分離してスコープの管理ができるのです。

f:id:kondoumh:20160410113556p:plain

Trac 入門 改訂版 執筆を振り返る

Books ITS

前回に引き続き、今回は改訂版執筆を振り返ってみます。

〔改訂〕Trac入門 ~ソフトウェア開発・プロジェクト管理活用ガイド (Software Design plus)

〔改訂〕Trac入門 ~ソフトウェア開発・プロジェクト管理活用ガイド (Software Design plus)

初版の時の ↓ みたいな内容です。

www.slideshare.net


Trac 入門」の改定話は2011年の秋ぐらいから頂いてました。当初は2012年の春ごろ出せるといいね! などと言ってました。初版当時は執筆陣がみな自社勤務だったんですが、いまや所属会社や常駐先もバラバラになってしまい、顔を合わせることもめったにありません。そこでパブリックな場所に検証環境が必要だねってことで、さくらインターネットVPS 借りて CentOS 上に Trac 環境を構築しました。ここまでは順調だったんですが、その後みんな公私共に忙しくなってしまい、ちゃんと取りかかれたのは、当初目標だった 2012 年の春。
私が担当している 2章・3章も 初版では一気に書き上げた気がしますが、2ヶ月ぐらいかかって修正が完了。休日深夜とか早朝しか作業ができず、なかなか進みませんでした。

共同で書いてる 6章(逆引き) も、追加内容を検討し VPS で検証しながら原稿を書いたりしているうちに真夏を迎えました。脱稿は8月下旬。脱稿までに Trac 1.0 が出そうだなあ、出るのかなあとウォッチしていましたが、執筆中は出なくて、9月に入ってからやっとリリースされました。リリース前から CSS とか 画面レイアウトが少々変化してることが分かってたので相当量のスクリーンショット撮り直しが予想されてました。まあ 1.0 対応は校正しながらだね〜ってことで 初校 は10月から開始。
送られてきた初校ゲラを見ると漫画もイラストもパワーアップしてる。いいね! などといいながら、緩やかペースで校正と 1.0 検証が続きます。VPSTrac をバージョンアップして、プラグインの動作を検証したり、スクリーンショットを撮り直したり・・そういえば、初版が出た時も Trac 0.10 ベースで書いていて校正中に Trac 0.11 がリリースされたためかなり加筆修正で苦労したのでした。Trac 入門は 偶然にも Trac のメジャーバージョンアップと共に世に出ているんです。

検証と修正はなんだかんだで師走までかかり、なんとか年内に初校が終わりました。年明け早々から再校作業開始して2月中旬やっとすべての作業が完了しました。

初版には、開発チームにテスターの「まめぞう君」がいましたが、改訂版ではヘルプデスクのみちこさんに変わっています。これは、初版に女子が登場しなくて残念だったのと、イラストレーターの方がワンカットだけ登場させてくれた女の子が可愛かったから。このため、あちこちに手が入りました。あのズッコケ開発チームも実稼働するソフトウェアを保守しながら開発を続けているようです。

初版ではまえがきの後の扉にワインバーグ先生の言葉を入れてたのですが、改訂版では各章の扉にそれらしい格言を入れたりしてみました。各章に4コママンガを入れよう! って盛り上がったりしたのですが、ネームを考えたりする時間もなくポシャりました。

前の記事にも書きましたが、大規模なプロジェクトで構成管理やリリース管理を担当したりして、私自身、本当に「こんどう」状態になってました。当プロジェクトでは、Jenkins 執事さんも大活躍。いろんな技を覚えました。Git も会社のプロジェクトで使い始めたりと 5年の月日の流れを感じます。

カバーデザインですが、初版は Trac のシンプルな画面をそのままデザインしたような、白に Trac ロゴカラーと同じ赤のタイトル文字(一部で白本とも呼ばれていました)。今回は、Trac のロゴの足跡が一面の雪に点々とついている写真になりました。タイトル文字は青になり、白本のイメージも残しつつ新しさを印象づけています。他にも色々なデザイン案を見せていただき面白かったです。

執筆スタイルも初版の時とはかなり変わった気がします。

初版の時はまず Word で書いて Subversion リポジトリーで管理していましたが、改訂版では、Google Drive に初版のテキスト原稿を突っ込んで Google Docs で編集するスタイルを取りました。ほぼ Word っぽく使えて図も描けたりして Office がなくても Chrome だけで執筆が進みました。

入稿できる感じになった時点で、Google Docs から Word 形式にエクスポートして、Dropbox で共有しました。Google DocsDropbox も版管理ができて、Subversion のようにコミットも要らないのが楽でした。

初版の入稿は、最初メールで、校正は紙のやり取りでした。最後の方は、PDF コメントでしたが。今回は画面キャプチャーとWord ファイルを Dropbox の共有フォルダーで入稿し、初校からは PDF ファイルにコメントを入れ、Dropbox の共有フォルダーに置くという流れで作業を進めました。PDF へのコメントは Mac の人はプレビュー、Windows ユーザーは PDF-XChange Viewer を使用。相互運用もほぼ問題なく出来ました(プレビューだと、コメントへの返信ができなくて、プレビューで上書きしたら返信が消えた ということはありましたが)。

PDF は Retina ディスプレイの iPad で GoodReader などを使うと印刷したみたいなクオリティーで読めるので、iPad 片手に、パソコンで PDF にコメント入れるというスタイルでやってみました。GoodReader でもコメント入力できますが、入力はやはりパソコンの方が格段に速いので。初版の時はかなり紙を使いましたが今回はペーパーレス化が出来てよかったです。

オフラインの打ち合わせは技術評論社で集まったのを入れて3回ぐらい、あとは、初版の時と同様 Lingr でコミュニケーションしてました。SNS とかでもよかったんですが、Lingr は専用のルームが作れるし使い慣れてるというのが大きかったです。Lingr も初版が出た1年後ぐらいに一度サービス終了して、また復活してるんですよね。iOS アプリもあるしなにげに便利です。

纏めますと、初版→改訂版で

  • ローカルの Office 主体 → ブラウザとクラウドサービス主体
  • 郵便・メールで入稿 → ストレージサービスで入稿
  • SVN で版管理 → ストレージサービスの履歴で間に合う
  • パソコン主体 → パソコン主体だが、スマートフォンタブレットがサポート
  • オフラインますます減少

書きおろしと改訂、単著と共著ではまた違うと思うのですが、時の流れを感じます。

Trac はチーム開発をサポートするツールですが、Trac 入門も遠隔地メンバーによるチーム執筆。いろいろなツールやサービスのお世話になりながらなんとか完了することができました。