Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GitHub Projectsにおける チケットの ステータス更新自動化について
Search
NearMeの技術発表資料です
PRO
July 30, 2024
Programming
1
52
GitHub Projectsにおける チケットの ステータス更新自動化について
NearMeの技術発表資料です
PRO
July 30, 2024
Tweet
Share
More Decks by NearMeの技術発表資料です
See All by NearMeの技術発表資料です
ガウス過程回帰とベイズ最適化
nearme_tech
PRO
0
22
確率的プログラミング入門
nearme_tech
PRO
2
31
Observability and OpenTelemetry
nearme_tech
PRO
2
23
観察研究における因果推論
nearme_tech
PRO
1
68
React
nearme_tech
PRO
2
31
Architecture Decision Record (ADR)
nearme_tech
PRO
1
810
遺伝的アルゴリズムを実装する
nearme_tech
PRO
1
40
Fractional Derivative!
nearme_tech
PRO
1
34
2つの曲線を比較する方法ってあるの? 〜フレシェ距離を試してみた〜 with Python
nearme_tech
PRO
1
270
Other Decks in Programming
See All in Programming
Duckdb-Wasmでローカルダッシュボードを作ってみた
nkforwork
0
110
Content Security Policy入門 セキュリティ設定と 違反レポートのはじめ方 / Introduction to Content Security Policy Getting Started with Security Configuration and Violation Reporting
uskey512
1
510
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
5
1.4k
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024
falcon8823
6
2.8k
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
160
Make Impossible States Impossibleを 意識してReactのPropsを設計しよう
ikumatadokoro
0
150
ローコードSaaSのUXを向上させるためのTypeScript
taro28
1
500
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.3k
【Kaigi on Rails 2024】YOUTRUST スポンサーLT
krpk1900
1
320
Jakarta EE meets AI
ivargrimstad
0
310
型付き API リクエストを実現するいくつかの手法とその選択 / Typed API Request
euxn23
5
1.8k
Click-free releases & the making of a CLI app
oheyadam
2
110
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
20
1.1k
We Have a Design System, Now What?
morganepeng
50
7.2k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
A Tale of Four Properties
chriscoyier
156
23k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Thoughts on Productivity
jonyablonski
67
4.3k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
506
140k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Transcript
0 GitHub Projectsにおける チケットの ステータス更新⾃動化について 2024-07-26 第100回NearMe技術勉強会 YO
1 目次 • Projectsでのチケット管理 • Projectsの機能を使って行える自動化 • Actionsを使わないとできない自動化 • ワークフローを作ってみて
2 要約 • GitHub Projects (V2)で複数のRepositoryのチケットを管理する • チケットのステータス更新を自動化したい • ステータス更新自動化の際、UI上で完結するもの(Projectsの
workflow)と、ワークフローの設定を記述しないといけないもの (GitHub Actions)がある • Personal Access Tokenの設定方法については割愛する
3 Projectsでのチケット管理 理想の運用 • マネージャーから見てチケットのステータス、各人の業務量が分かる状態 • 開発者は事務的な作業を頑張らなくてもよい状態 自動化の背景 • 「どの人がどんなタスクを持っている」のか都度コミュニケーションが発生してしまう
• 開発者がチケットのステータス更新を忘れてしまうことで、マネージャーはリ アルタイムなチケットの進捗が分からない • (今後)チケット更新がリアルタイムで行われないと、チケットを消化するのに 要した実測値が正しくとれない
4 Projectsでのチケット管理 Projectとは? • UserまたはOrganizationに紐づく機能 • 複数のRepositoryのIssueを一覧化したりIssueをボードに並べることが できる(ソート、フィルター、グルーピング) なぜGitHub Projects?
• マネージャーは複数のリポジトリのチケットを一元的に管理したい • 開発者側の既存の運用をなるべく変えたくない(GitHubのIssueで開発 のチケットを管理、チケット管理のためにツールを増やしたくない)
5 Projectsの機能を使って行える自動化 今回の説明で使用するProject • スタータスは以下の5つ ◦ 📪とりあえず ◦ 📚着手前 ◦
⌨開発中 ◦ 👀レビュー中 ◦ ✅マージ済み
6 Projectsの機能を使って行える自動化 トリガー アクション Repositoryに新しいIssueが追加 Projectsに追加する Issueに紐づいたPull Requestが マージされた Issueのステータスを「✅マージ済
み」にする Issueのステータスが「✅マージ済 み」になった Issueをクローズする
7 Actionsを使わないとできない自動化 Actionsとは? • Repositoryに紐づく機能 • Repository内での操作を自動化できる
8 Actionsを使わないとできない自動化 トリガー アクション IssueにDraft PRが追加 Issueのステータスを「⌨開発中」にす る IssueにPRが追加 Issueのステータスを「👀レビュー中」
にする Issueに追加されたDraft PRがPRに変更 された 「⌨開発中」から「👀レビュー中」に移動 する Issueに追加されたPRがDraft PRに変更 された 「👀レビュー中」から「⌨開発中」に移動 する Issueにassigneeが追加 「📪とりあえず」から「📚着手前」に移動 する
9 Actionsを使わないとできない自動化 ①起案 ②棚卸 ③実装はされたが 承認はまだのもの ここの自動化 • 「実装が作られた」を感知 •
Project上でチケットを移動 ④承認
10 Actionsを使わないとできない自動化 1. 開発者がPull Requestを作成する(トリガー 1) 2. GitHub ActionsがPull Requestの説明を読んで、メンションさ
れたIssueに作成されたPull Requestの種類に応じたコメント を書きに行く(トリガー 2) 3. GitHub ActionsがIssueにコメントされたのを感知して、コメン ト内容に応じてProject上でIssueを移動 • Issueにコメントが記載 される • PR作成 • Draft PR作成 • Draft PR→PR • 閉じられてたPR再開 YO YO
11 Actionsを使わないとできない自動化 作成したワークフロー • キーワード ◦ Expressions : ${{ }}を使うことで環境変数などをワークフロー内に埋め込める
機能 ◦ Contexts : トリガーやジョブに関する情報にアクセスするための機能 ◦ GitHub CLI : GitHubを使用するためのコマンドラインツール • 以下のGistのコードで解説 https://gist.github.com/yutaokamoto/1bd9bffc70319fb09db256b7e193658c
12 ワークフローを作ってみて 苦労した点 • GitHub Actionsに慣れること ◦ Expressions ◦ Contexts
◦ GitHub CLI • GitHub Projects (Classic)だとコメントを記載するのが簡単にできるっぽ い • Issueに関するワークフローはメインのブランチにマージされないと実行 されない • Actionが書き込んだコメントに改行が入ってしまう
13 ワークフローを作ってみて 苦労した点 • GitHub上で自動化の実行を行ってみないと分からないことも多く、デ バッグがやりづらかった ◦ debug loggingというログを詳し目に出してくれる機能に途中で気づいた
14 Thank you