fbpx

GitLabのValue stream analyticsを触ってみた #gitlab #gitlabjp

DevOpsGitLabk-shoda

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。


New call-to-action

こんにちは、スクラムマスターのしょーだです！
クリエーションラインではGitLabのサポートを行っているのですが、自分はこれまでGitHubを使うことが多くほとんど触ったことがありませんでした。
しかし今後はGitLabを使うことも多くなりそうなのでいろいろ調査してみると面白そうな機能がたくさんあり、ドキュメントをみてるとValue stream analytics(VSA)という機能を発見！
最近DASA DevOpsの資格も取ったことでこの辺りに興味があり、調査をしながらいろいろ触ってみました。

VSAとは

ソフトウェア開発の速度を可視化するために、開発プロセスの各ステージに関する時間やそのほかの指標を表示する機能と定義されてます。Value Streamは最初の要求から顧客による価値の実現まで、顧客に価値を付加するために行われる一連のアクションのことなので、それぞれのアクションに関する指標を自動で取得・表示してくれるようです。
また、取得した情報をもとにKey metrics とDORA metrics というものも表示されます。
ultimateに限られていますが、DORA metricsはfourkeyメトリクスを表示してくれるようなのでチームの生産性を測る上ではとても役に立ちそうです。

GitHubの場合、このようなメトリクスを取得するにはほかのツールと組み合わせないといけなかったですが、GitLabの場合は標準でついているので導入が容易となります（新たなツールを導入するのに上長の承認が必要な組織だったりする時は、標準でついていると嬉しいですね）

ステージについて

VSAで定義されているのはIssue/Plan/Code/Test/Review/Stagingの６ステージ。各ステージ共にそれぞれでかかった時間の中央値を表示するようです。

マニュアルなどを読みながら自分なりにまとめてみました。

ステージ 開始イベント 終了イベント 意味
Issue Issueの作成 Issueをマイルストーンに関連付け or ボードに関連付けしたラベルを最初に追加 アイデア・問題に取り組み始めるまでどのくらいかかったのか？
Plan Issueをマイルストーンに関連付け or ボードに関連付けしたラベルを最初に追加 最初のコミットをブランチにPush。※Pushしたコミットの最低１つにはIssue番号(#XX)が含まれてる必要がある 計画してから最初にコミットするまでどのくらい時間がかかったのか？
Code 最初のコミットをブランチにPush マージリクエストを作成 MRを作るまでどのくらい時間がかかったのか？
Test マージリクエストのCI/CDパイプライン開始 マージリクエストのCI/CDパイプライン終了 CI/CDでコードをテストするのにどのくらい時間がかかったのか？
Review マージリクエストの作成 マージリクエストのクローズ マージリクエストのレビューにどのくらい時間がかかったのか？
Staging マージリクエストのクローズ Production環境への最初にデプロイ マージしてから本番環境にデプロイするまでどのくらい時間がかかったのか？

それぞれ実際に動かして確認してみました

Issue

まずは新しくIssueを作成してみます。

  • Issueを作成

  • VSAではKey metricsのNew Issueが増えましたが、そのほかに変化はなし

  • Issueにマイルストーンを設定して見たところ、Issueが測定された

今回はお試しのためIssueを作ってからMilestoneを設定するまで短い時間となりましたが、実際には要件決め・受入条件・見積もり・いつ作業するのか など色々と決めることがあると思います。
このため、一つ一つのIssueが大きかったり、何ヶ月もの計画を立てていたりするとこのステージがボトルネックとなりそうです。

Plan

前のステージでIssueにマイルストーンを関連付けしているのでPlanステージの計測は始まってるはずなので、計測を終了するためにコードを書き換えてコミットとプッシュをおこなっていきます。この時、コミットメッセージにIssue番号を含めるのを忘れないように注意します。

➜  gitlab-study git:(main) git checkout -b issue
➜  gitlab-study git:(issue) ✗ git commit -am "Issueのタスクを実施 #20"
➜  gitlab-study git:(issue) git push origin issue

  • Planの時間が測定された

ここで集計される時間はPushまでの時間ではなく、Commitまでの時間のようです。（ただし集計のトリガーにPushが必要）

コミットメッセージにIssue番号を含めるのを忘れると集計されなくなってしまうので、もしこの機能を使うのであればチームでIssue番号を含めるルールが必要となりますね。
また、コードをたくさん書いてからコミットするような開発スタイルだとPlanステージとして正確に計測できなくなってしまうため、こまめなコミットを行なっていくスタイルに変更した方が良いのかもしれません。

Code

Codeは最初のコミットからマージリクエスト作成までの時間なので、マージリクエストを作成してみます。

  • MRの作成

  • MRを作成しただけでは集計されない

MRとIssueを関連付けするため課題クローズ パターンを記載する必要があるようです。

  • MRのDescriptionに課題クローズパターンを設定

  • 無事Codeも測定された

課題クローズパターンが必要となるため、忘れないようにMRのテンプレートを用意しておくのが良いかもしれません。

ただ、MRのクローズとIssueのクローズを同時に行いたくないケース（例えばマージ後に受け入れ検査を行なってからIssueを閉じるなど）もあるので、VSAをうまく活用するためにはもう少し調査が必要となりそうです。

Test

TestはMRのパイプラインの開始と終了で集計されるため、MR作成後に測定されていると思いましたが表示されません。
もしかするとマージ後のコミットのパイプラインで動く？と思ってマージまでして見ましたが、それでもTestが計測されませんでした。

  • MRのパイプラインが終わっても測定されない

ちなみにこの時のCIは、rulesでマージ後にdeployステージが動く設定としていました。

stages:
  - build
  - test
  - deploy
...
development_deploy-job:
  stage: deploy
  environment: development
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH #このルールがあるためマージ前は動作しない
deploy-job:
  stage: deploy
  script:
    - echo Deploy to production server
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == production
      when: manual

もしかすると、 gitlab-ci.ymlに定義しているstagesを全て実行する必要がある？

試しに別のIssueを作り、CIでルール設定していた部分を削除して実行してみました。

stages:          # List of stages for jobs, and their order of execution
  - build
  - test
  - deploy
...
development_deploy-job:
  stage: deploy
  environment: development
  script:
    - echo Deploying application...
    - echo Application successfully deployed.
    # ここにあったルールを削除
deploy-job:
  stage: deploy
  script:
    - echo Deploy to production server
    - echo Application successfully deployed.
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # mainブランチコミットでDeployが動くように変更
      when: manual

この状態で確認して見たところ、Testステージも集計されその後のデプロイまで一通りデータを取ることができました。

  • Testが測定された

まだ調査が足りないので断定はできませんがMR作成時のパイプラインでstagesを全て動かす必要がありそうです。
VSAをうまく使うためにはCIの設計に気を付けなければなりませんね。

Review

MRがクローズされるまでなので、マージしてみます

  • MRのマージを実施

  • Review時間が測定された

こちらは想定通りの動作をしてくれました。

ちなみに、VSA以外にPREMIUM以上のユーザであればCode Review analyticsやMerge request analytics というものもあり、これらで各MRの情報を見ることができるようです。
Review時間が長すぎる場合、これらの情報を使用してボトルネックなどの問題の特定に活用できるかもしれません。

Staging

最後にStagingステージです。
このステージはMRがマージされてから本番にリリースされるまでの時間のため、CIで本番環境(Production)へのdeploy設定が必要となります。
今回の.gitlab-ci.ymlの設定は以下

deploy-job:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "production"
      when: manual

ちなみにdeployはマニュアル設定にしていたため、再生ボタンをクリックしてdeployを実行します。

  • deployの手動実行

  • deployが終わると、Stagingが測定された

マージ後の受け入れテストや他のコードと合わせてリリースするなどの場合、このステージがボトルネックになる可能性がありそうです。

数値として見られることで、ムダなプロセスがないか？Issue単位でリリースする方法はないか？Feature Flagが導入できないか？など運用ルールの見直しのきっかけにできそうです。

Key metrics

Key metricsとしては

  • Lead Time: Issueが作成されてからクローズされるまでの時間の中央値
  • Cycle Time: 最初のコミットからIssueがクローズされるまでの時間の中央値。GitLabは、リンクされた課題のマージリクエストの最初のコミットからIssueがクローズされるまで
  • New Issue: 作成された新しいIssueの数
  • Commit: デフォルトブランチにPushされたCommitの数
  • Deploys: 本番環境へデプロイした数

の５つの項目（FreeプランだとNew Issue,Commit , Deploys の３つ）です。

ドキュメントを見るとLead Timeは単純にIssueが作成されてからCloseされるまでと思っていましたが、上記でTestステージが計測されていなかった時にLead Timeも計測されていなかったことから、全ステージで計測が行われていることが条件になっていそうです。

  • Testステージが計測されていない場合、Lead Timeも計測されていない

  • 全てのステージが計測されていると、Lead Timeも計測されている

一方、Cycle Timeは計測されませんでした。。
コミットメッセージやMRの説明にIssue番号を書いていたのですが計測されていません。過去に触っていた時は計測されていた時もあったので、何か足りてない可能性があります。
ここについては継続して調査してみようと思います。

DORA metrics

DevOps Research and Assessment (DORA) metricsはLeanとDevOpsの科学でも紹介されている Four Keys metrics になります。
今回は、Change Failure Rate(変更失敗率)とTime to Restore Service(サービスの復旧時間)を調査するため、IncidentのIssueを作成してみます。

  • TypeをIncidentとしてIssueを作成

  • 変更失敗率が100％に変化

GitLabでは、特定の期間におけるインシデントの数を本番環境へのデプロイの数で割ったものとして測定しており、今回はDeploy数１に対してIncident数も１なのでChange Failure Rateは１００％となってます。

続いてIncidentのIssueに対して開発〜デプロイまで行いました。

  • 開発〜デプロイまで実施後

Time to Restore Serviceが計測され0daysとなり、Change Failure Rateも50%に減少しました。

DORA metricsはULTIMATE限定の機能となりますが、IssueのTypeをIncidentにするだけで簡単に計測できるのは便利ですね！

最後に

CommitコメントやMRに課題クローズパターンを記載するなど、ところどころクセがありそうな部分もありますが、GitLab単体でここまでメトリクスを収集できるのは便利だと感じました。
まだ不明点もあるので調査を引き続きしつつ、実際のプロジェクトで使ってみて使い勝手や収集したメトリクスをどのように活かすのか試していきたいと思います！


New call-to-action



New call-to-action

Author

庄田宏平

    札幌在住のスクラムマスター
    チームが少しずつ良くなるように全力を尽くしてます！

    庄田宏平の記事一覧

    新規CTA