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から取得しても良さそう。



Top comments (0)

Timeless DEV post...

How to write a kickass README

Arguably the single most important piece of documentation for any open source project is the README. A good README not only informs people what the project does and who it is for but also how they use and contribute to it.

If you write a README without sufficient explanation of what your project does or how people can use it then it pretty much defeats the purpose of being open source as other developers are less likely to engage with or contribute towards it.