DEV Community

Motoki Tokifuji
Motoki Tokifuji

Posted on • Updated on

Gitlab Issues BoardでProjectを横断してIssue管理したいからやってみたこと

前提

  1. Gitlab Issues Board便利だよねっていうマネージャがいる
  2. 案件・クライアント毎にProjects/Sub Groupsを分けてIssueを管理している
  3. 1 Sprintを1週間とし、その週に立ったIssueは翌週の水曜までにテスト環境にDeploy
  4. ある程度DispatchingできるTeamである

最初にやったこと

  • Googleフォーム→Gitlab Service Desk→Issue(Project)

運用内容

  1. Googleフォームから投稿
  2. Google Apps Scriptからメール送信
  3. Gitlab Service Deskで1次受け用のGitlab ProjectにIssueが立つ
  4. Dispatcherが振り分け
  5. StatusはLabelでtodo, wip, doneくらい持ってるが初期で割り振られていない
  6. Issue Close条件
    1. クライアントの検収確認後
    2. 案件・クライアントのProjectにIssueをmoveする
    3. ↑でmoveしたIssueをCloseする(moveすると元のIssueは自動的にCloseする)

メリット

  1. 開発工数が低い
    1. Googleフォーム
    2. テンプレートに合わせてメール本文をBuildする
    3. Service DeskにGmailApp.sendmail()する
  2. ランニングコストがG Suiteに含まれるので実質無料

課題

  1. 案件・クライアントがわかりにくい
    1. IssueのDescriptionにあってややこしい
  2. Service Desk経由からだとIssueの細かい表現の設定ができない
    1. Confidential Issueになる
    2. Labelを付与できない
    3. Assigneeを設定できない

次にやったこと

  • Google Apps Script→Gitlab APIからPOST→Issue(Project)

運用内容

  1. Google Apps Scriptのフォームから投稿
  2. Google Apps ScriptからGitlab APIにPOST
  3. Gitlab ProjectにIssueが立つ
  4. Issue Close条件
    1. クライアントの検収確認後
    2. Commit/Merge Requestにproject#IssueNoを含めて関連付けする

メリット

  1. ランニングコストがG Suiteに含まれるので実質無料
  2. いくつか追加で自動化
    1. Assignee設定
    2. 案件・クライアントLabel
    3. Project横断はCommit/MR messageにproject#IssueNoを含めて関連付けする

課題

  1. 最初の案に比べると開発工数高い
  2. Slack通知のChannel分けをどうしたらいいか?(今は案件・クライアント毎にChannelがある)
  3. 案件・クライアント情報及びGitlab Group User情報などをGoogle Spreadsheetから参照してフォームのSelect boxに出すようなことをやっていたけど、Gitlab APIから取得しても良さそう。

まとめ

まだまだ始めたばかりなので運用しながらKPTするぞい。

Discussion (0)