GitLabのIssue運用で悩んでいること
本文書の目的
完全にポエムです。悩みを書き連ねただけです。
GitLab でも GitHub でも同じことになるのではないかと思います。
この文書に有用な情報は含まれません。
前提条件
- SIer
- テスト担当者が存在する
- 顧客と GitLab を共有できない(ので別の不具合管理表 Excel がある)
お約束事項
プルリクエスト(以下 PR。GitLab ではマージリクエストだが通りが良いので PR と呼ぶ)
運用
基本的な運用フローとして、
バグ発生 →Issue 作成 → 担当者修正 → テスト担当者テスト → リリース
ソースコードの修正フローは
開発者ブランチ →PR→development にマージ → 社内検証環境[develop]→ 客先環境[master]
というフローで開発しているが、Issue の運用がイマイチうまく行っていない気がする。
と言うことでつらい所を列挙する。
#ただ、元々使っていた Redmine の時に比べれば色々とよくなっているとは思っている。
#なので Gitlab がダメっていう話では全然ないです。
チケットの Close =テスト完了問題
テスト担当者にテスト依頼をした時点で、開発者的にはテストが完了して、さらに
PR もマージ済み。なので、次回リリース時の更新に変更が含まれてしまうが、それまでに
テスト担当者のテストが間に合わないと、開発者のテストだけで客先にリリースされて
しまう。(しまった)。かといって、PR をマージしないと社内の検証環境にも反映できないし、
社内検証環境 → 客先環境のリリースに関門を作るのは負荷的に不可だし…
わざわざ、テスト通ってない Issue の PR を客先リリース前に revert するのもちょっと…
GitLab CI の動画を見ると、PR を自動的にステージング環境にデプロイしてテストすれば OK
PR の画面からデプロイするブランチも変えられるよ!みたいな図になっているけれども、
テスト担当者がブランチの内容までちゃんと理解してないとダメか・・・みたいな状態になっている。
課題管理表との整合性がとれない
顧客とのやりとり用 Excel の内容が GitLab に自動反映されない。
マージ後にわざわざ XLS シートに色々書き込みするとか面倒。何より、Excel シートじゃ
やりとりが全然残らない、検索つらい。なので GitLab で出来るだけやりたいが、同期がつらい。
課題管理表の新しい Issue を GitLab に転記する作業が割と面倒。
これは解決策が簡単で、顧客にも GitLab 使って貰えばいいと分かっているけれども、
担当者に説明するのはしんどい UI してる(なにせ英語。英語の壁は意外と高い)
Markdown がつらい
GitHub フレーバーの Markdown はつらくないが、GitLab の Markdown は純粋な Markdown なので
文章中の改行がそのまま反映されない。文末にスペース 2 個入れて改行か、br タグ書くか
改行を 2 個連打するかのどれかをする必要がある。これがつらい。本当につらい。
元々は GitHub フレーバーだったのになぜ改悪したのか、これがわからない。
というより、Markdown の仕様としてなぜこんな(2 スペース)仕様にしたのか理解できない。
Issue の粒度が揃わない
例えば、同一仕様の画面が 3 個あったとして、(悪い事だけれど)内容はコピペだったとする。
ある人は、画面一個= 1 Issue として 3 個の Issue を切った。
またある人は Issue 本文にチェックボックスを入れて、1 Issue とした。
個人的にはチェックボックスのが好きだけれども、どっちかに揃えたい。これはプロジェクト
開始時にちゃんと話をすれば良かった。という話ではあるけれども。
タグの管理がつらい その1 タグ管理
標準で、GitHub と同じタグが作成されるが、タグの説明がプロジェクトごとなので標準化しにくい。
英語のタグだと分かりづらいので日本語化したタグを全プロジェクトに配りたいが、それは今の所
できない。仕方ないので、手で入れているが、なんだかなぁ。
#標準のタグのセットみたいなのを定義できるが、既存プロジェクトには反映されない。新規なら反映される?
タグの管理がつらい その2 ワークフロー
ワークフローにあわせてタグを付け外しして欲しいが、周知されておらずタグが適当になっている。
| ステージ | 期待するタグ操作 |
| Issue作成 | bugとか分類タグを付ける |
| 担当者修正 | QAタグ付ける |
| テスト担当者テスト | Issueクローズ |
Discussion