GitLab Cycle Analytics
GitLab は機能がたくさんあって全機能を把握している方は少ないのではないでしょうか? 私もそうです。
最近追加された Cycle Analytics については正直よくわかっていません。プロジェクトの健全性を推し量るための指針として使えそうなのですが、いまいち何がどうなっているのか分かりません。
New Issues とか Commits などはまだ分かるのですが、Stage にあるほとんどのものは Not enough data (十分なデータがない) となってましてちんぷんかんぷんです。Issue を追加したり終了させたりしても変化がないことが多いです。
というわけで、マニュアルを読みながらまとめていきます。
そもそも Cycle Analytics って?
GitLab は去年の 8 月に Idea to Production という目標を掲げました。GitLab とそのファミリーでアイデアから製品まで一貫した開発をサポートしようということのようです。
その中の一つとして、プロジェクトの開発速度を可視化するために 8.12 (2016/9) で導入され、8.14 (2016/11) で完成したもののようです。
Cycle Analyticis は各ステージごとに時間計測をし、アイデアがプロダクションになるまでどれくらい時間がかかったかが分かるようです。また、GitLab Flow 向けのようです。(専用ということはないと思いますが...)
うまく使えば、プロジェクトの進行をより早めるための指標になりそうなんですよね!
ステージ
Cycle Analytics は開発を七つのステージに分割し、それぞれかかった時間を計測し、その中央値を (Median となっているので平均値ではないようです) 表示します。
ヘルプを読みながらまとめてみます。
-
Issue- Issue が作られてから Milestone や Board に登録されるまで -
Plan- Milestone や Board に登録されている Issue に対してブランチがプッシュされるまで -
Code- ブランチに対し Merge Request が作られるまで -
Test- テスト -
Review- Merge Request が作られてから、それがマージされるまで -
Staging- Merge Request がマージされてから、Deploy to productionでプロダクションに持って行くまで -
Production- テストを除く全ての時間
よくわからないですね! (笑) ヘルプを読み進めていきます。
Issue
Issue が作られてから Milestone や Board に登録されるまでの時間を各 Issue ごとに計測しているようです。左側にはその中央値が表示されます。
スクリーンショットは GitLab CE の Cyrcle Analytics です。
この中の over 7h となっている#28808 ですが、2/28 14:20 に登録され、2/28 21:34 に Milestone に登録されました。ですので 7hr 14mins ってことらしいです。
ところで Issue Board を使って Issue を作っている限りは即座に Issue が Board に登録されるため、Issue の計測値は 0 です。よって、Issue Board を活用している限り、中央値は less than a minute になりやすく、意味のある値が出てくるか疑問です...
Plan
Issue ステージから最初にコードがプッシュされるまでの時間を各 Issue ごとに計測しているようです。要するに、Issue をやると決めてからコミットするまでの間が Plan (計画) だろうということのようです。(Push 時間ではなく、コミット時間っぽい)
Issue とコミットを関連付けるため、コミットメッセージに #15 のように Issue 番号を含める必要があるようです。また first commit to branch と書かれているのですが、おそらく master は除外されている気がします。
私は最近、結構なコードを書いてからコミットをすることが多いのですが、Cycle Analytics を活かそうとすると、そういうスタイルはやめたほうが良さそうですね!
あと、コミットメッセージには Issue 番号をちゃんと書きましょう!
Code
Code ステージは Plan ステージから Merge Request が作られるまでの時間を各 Merge Request ごとに計測しているようです。Merge Request が作られたということで、 Plan (計画) ではなく、Code (コーディング) が完了し他人に見せられる状態になったということのようです。
Issue とコミットと Merge Request を関連付けるため、Merge Request の Description に Closes #15 のようにして、Merge Request がマージされたら自動で Issue が完了するようにしなければならないようです。Automatic issue closing を参考。
ところで、Merge Request がマージされたら同時に関連 Issue が閉じられる機能ですが、これを使うと Issue Board の Done に入らないようで、ちょっと使いづらいんですよね。
Test
Test ステージはちょっと他と違い、前回の直前のステージからの時間ではなく、Merge Request で発生した CI Pipeline の実行時間の合計のようです。(Exclude master と書かれている通り、ブランチのみ)
Review
Review ステージは Merge Request が作られてからマージされるまでの間の時間を各 Merge Request ごとに計測しているようです。Merge Request が Open されている間は Review (レビュー) 中ということのようです。
Staging
Staging ステージは Merge Request がマージされてから production deploy がなされるまでの時間です。マージされた機能はすぐにステージング状態に入っていて、プロダクションに入るまではその状態、ということのようです。
完成した機能が利用者が使えるようになるまでの時間と考えると分かりやすい気がします。
Production
Production ステージはアイデアからプロダクションまでの間の総合時間のようです。Plan から Staging の全ての時間を合計していると書かれています。(ただし、Test は除く)
この総合時間は、思いついてからそれが実際に利用者が使えるようになるまでの時間になるため、Issue を起票したひとはこの時間を見ながら思いを馳せるのでしょうか?
まとめ
各ステージはこのように分かれています。図で書いてみるとそれほど難しくはないですね。
どういった形で計測されるかはなんとなく分かりました。でも、これらの計測時間にどういった意味があるかはよく分かりませんでした。
また、ブランチのみという計測もあるので、GitLab Flow でないにしても、Issue はやらなければいけないことを、実際の作業は Merge Request をというスタイルを守らないと、正しい計測値は出てこないようです。
このあたり、もう少し詳しい記事が欲しいです。
結局わからなかったこと
- どうやって計測値を使うのか?
-
Planにmasterへのコミットは含まれるのか? - いつ計測がされるのか? リアルタイムでなはないっぽい?
追記 (3/1)
以下の三つをやってはじめて Issue・Plan・Code の三箇所 Issue が (Code の場合は Merge Request) が表示されました。待てば表示されるというものでもないようです。
- Issue を登録する
- ブランチを作成して
#15とコミットログに含めてコミットして、プッシュする - Merge Request を
DescripionにCloses #15と書いて作成する
