ボットによるリリースフロー改善
こんにちは。バーチャルキャストクライアント開発のkakunpc(かーくん)です。
今回の内容はちょっとクライアント開発から離れたボットの話です。
リリースフローを見直す
さて、みなさんはアプリとかツールを開発したとき、リリース手順はどのようにやっていますか？
リリース手順書と書かれた手順に従って１人の人間が手作業で作業しているのでしょうか？
それともそのような手順書はなく、１人の人間がアプリのビルドからリリースまで手作業で行っているのでしょうか？
初めてのリリースではまだ手順書を残しておく余裕はなく、２～３回目も最初にリリース作業したからという理由で１人がずっとリリース作業をする・・・
そのようにして気がつけば属人化してしまうことがあるかと思います。
また、複数人が一気にアプリをより良くなるよう開発し、更新内容が肥大化したとき、
リリース担当者から「さて、今回のリリースの内容をブログにまとめるから前のリリースからやったこと全部書いて」
と言われた時、１週間・・・いやもっと前の１ヶ月前からの作業内容をリリース担当者に伝える作業が発生してしまい、常日頃からメモってない人は過去のログから追いかけたりと、
とてもじゃありませんが手作業でやっていたらミスや抜けが発生してしまいます。
また、1ヶ月前作業した時に確認した時はバグが発生していなかったものも、リリース直前になってバグが発生してしまいそれが気づかずにリリースされてしまうなど
こういった確認作業でさえも抜けが発生してしまいます。
このような問題が発生してしまうのを防ぐためにバーチャルキャストではリリースの作業の一部はボットが行っています。
わかりやすいようにバーチャルキャストのリリースフローを図にしてみます。
バーチャルキャストのリリースフロー
この図では、
灰色の枠はボットが行う作業
緑色の枠は人が行う作業と色分けしています。
「ボットへリリース作業のお願い」するのはSlack上で、クライアント開発メンバーが全員居る公開チャンネルでのみ動作するようになっています。このようにすることで誰でもリリース作業はできますが勝手にリリース作業をしたりすることを防いでいます。
そして重要なのが、リリースブランチからプルリクエストを作る手順です。
この時ボットは今回適応されるすべての差分を取得し変更内容を抽出します。
機械的にカテゴリ毎に抽出してくれるので、今まで各人がリリース内容を報告していましたが、ボットがまとめてくれるためリリースノートも書きやすくなります。
また各作業のPull Requestにはその時必要な動作確認項目を書く項目があります。
作業者は作業した時必要なテストを予め書いておくことで、リリース前の動作確認で必要なテストができるようになります。
テストが必要ない場合は項目なしにもできるようになっています。
GitHubIssueを利用することによって、全員が一斉に動作確認できますし、リリース担当者はどこまで終わっているかひと目で分かるようになっています。
動作テストが完了しリリースが問題ないと判断されたら、リリース担当者はリリースボタンを押してリリース完了となります。
ボットの実装について
ではこのボットはどのように実装されているのか簡単に解説していきます。
ボットは .NET Core と SlackAPI を使ってSlackを監視し、
特定のメッセージが呼ばれたら GitHubAPI や gitコマンド を実行しています。
ボットはGCPで動かしていて24時間ずっと待機させています。
Gitを操作する
ボットはリリース用ブランチを作成するためにローカルでGitを操作するようになっています。Process.Start でGitコマンドを逐一発行しても良さそうですが、LibGit2Sharp が良さそうなので利用しています。
Pull Requestを作成する
Pull RequestはGitHubAPIを利用することで作成できます。
まずはリリース用ブランチを用意します。
バーチャルキャストでは origin/develop からそのままリリースブランチを作るようにしていますので、developのSHAを取得します。
|
1 2 3 |
var repository = new Repository("REPOSITORY_PATH_HERE"); var developBranch = repository.Branches.FirstOrDefault(x => x.FriendlyName == "develop"); developBranch.Commits.FirstOrDefault()?.Sha; |
SHAを取得してきたら、GitHubのAPIを呼び出してブランチを作成します。
Create a reference がブランチを作成するAPIなので呼び出します。
|
1 2 3 4 5 |
var url = $"{BaseUrl}/repos/{repository}/git/refs"; var json = $"{{ \"ref\": \"heads/release/1.0.0\", \"sha\": \"{sha}\" }}"; var client = new HttpClient(); var content = new StringContent(json, Encoding.UTF8, "application/json"); var response = await client.PostAsync(url, content); |
GitHubにリリース用ブランチができました。
Pull Requestの内容にリリースノートを書きますので、先に今までの差分をすべて取得します。
これはgitのlogコマンドが便利です。
|
1 |
git log 887d10..a6dbc44 |
このコマンドで 887d10 以降 ～ a6dbc44 までのコミットのログが取得できます。
LibGit2Sharpの場合はこのようなコードになります。
|
1 2 |
var commitFilter = new CommitFilter {IncludeReachableFrom = toSha, ExcludeReachableFrom = fromSha}; var logs = repository.Commits.QueryBy(commitFilter).ToList(); |
GitHubでPull Requestをマージしたログには必ず
|
1 |
Merge pull request #XXXX from .... |
と書かれており、この #XXXX の数字を取り出すことで今までのPull Requestが参照できるようになります。
取得してきたPull Requestの詳細は Get a single pull request を使うことで取得できます。
これを使ってリリースノートを作成します。
Pull Requestを作る準備が整ったので、GitHubAPIを使って作ります。
Pull Requestを作るAPIは Create a pull request
これをボットから叩くことでPull Requestが作成されます。
動作確認項目を作成する
Pull Requestと同じでIssueもGitHubAPIを使用することによって作成できます。
洗い出したPull Requestから動作確認項目を洗い出し、Issueに転記します。
この時すでに ✔が入っている項目は再度確認を要求するためにチェックを外します。
作業者はこのIssueを開き、動作ができたら ✔ をつけます。
すべて終わったかどうかはSlackでボットに聞くことで、確認できるようにもしておきます。
まとめ
このようにして普段は複雑でミスも多くなりがちなリリース作業の一部をボットにお願いすることによって、作業自体を楽にしたりミスを減らせます。
.NET Core と SlackAPI を使うことでC#でSlackBotを作れ、複雑なリリースフローも組めるので普段のリリース作業が大変と思っている方
またはこれからリリースするぞって思っているかた、ぜひ一度そのフローをボットで作業できるようにしてみてはどうでしょうか！
- Tag