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するぞい。