GitHub連携のあるアプリを構築する

4人のプロダクトスタジオにとって、納品の事実はすでに存在しています。プルリクエスト、マイルストーン、リリースタグの中にあります。問題は、クライアントがGitHubを読まないことです。だから金曜日は翻訳に消えます。Issueのステータスを表計算に写し、コミットメッセージをメールに書き直し、「あの機能はどこですか」という問いに、クライアントが開くはずのないボードのスクリーンショットで答える。

Klivのアプリは、この会話の両端を持てます。あなたのGitHub Organizationに接続し、双方向に働きます。あちら側で動作し、Issueを起票してラベルを付けます。あちら側で起きたことに反応し、マージとリリースを着いた瞬間に捕まえます。スタジオは仕事のある場所で働きつづけます。クライアントには、自分の言葉で話し、YAMLを見せないハブが渡ります。

接続は1回の認可であって、配管工事ではありません。 GitHub Organizationを一度つなぐだけです。トークンはプラットフォームが預かり、アプリのコードに貼り付けられることはありません。以降、アプリはIssueを起票し、コメントし、リリースを読めます。Webhookはマージやタグを、あなたの関数が処理するイベントとして届けます。

下書きは、人を待ちます。 変更履歴の項目はレビュー待ちの列に保留として並びます。誰かが「fix: race in webhook dedupe」を「リリースメールの重複がなくなりました」に書き直すまで、クライアントには何も届きません。この列は最初から備わっていて、誰が何を承認したかの監査記録も同じです。

この話には、GitHubが2つあります。 ハブはあなたのリポジトリと連携します。そしてハブ自身のソースコードも、リポジトリの中にあります。Klivはアプリをあなたが所有するリポジトリと双方向に同期します。仕事を報告する道具が、仕事のすぐ隣でバージョン管理されます。

クライアントがSlackにいるなら、Slackにも。 リリースは、各クライアントと共有しているチャンネルに要約を投稿できます。同じイベント、もうひとつの読み手。

GitHubは、多くの差込口のひとつです。この「動作し、反応する」型は、Slack、Notion、Linear、HubSpotほかにも届きます。どこまで届くのかは構築と拡張のページで。