ジモティーでサーバサイドとインフラを担当している吉田です。

前回は ISUCON10 に参加した話を投稿しました。今年もちょうど ISUCON11 を終えたばかりですが、残念ながら予選敗退となりました。ISUCON への参加はウェブエンジニアとしてのキャリアを見つめ直すとてもよい機会で、来年こそは決勝に進みたいと思っています。

さて、今回はジモティーのサーバサイドで1年ほど運用している、リリース作業の一部自動化の取り組みについて、背景から実施までをご紹介します。

従来のリリースフローとその課題
改善
まとめ
宣伝

従来のリリースフローとその課題

まず、弊社サーバサイドのリリースフローについて、当時の概要は次の様になっていました*1。

コードレビューを経て、トピックブランチを master ブランチにマージ（作業者: 各機能担当者）
リリース PR を作成（作業者: リリース担当者）
機能担当者にリリース前テスト環境での動作確認依頼（作業者: リリース担当者）
動作確認（作業者: 各機能担当者）
Jenkins のジョブを実行してリリース（作業者: リリース担当者）

リリース担当者はリリースしたいメンバーによる立候補制で、サーバサイドのメンバーであれば誰でもこの役割になる可能性があります*2。

この作業の1番の課題は、マージされた PR の「タイトル」「作成者」を目視で抜き出す事が大変な点です（図の2. および 3. に該当）。

詳細な流れは次の内容になります。

master ブランチへのコミットログの中からマージコミット (メッセージが Merge pull request #xxxx from jmty/xxxx) を確認
マージコミットの PR から「タイトル」「作成者」を確認
確認した「タイトル」をリリース PR の本文に入力
確認した「作成者」にリリース前テスト環境での動作確認を Slack のメンションで依頼

また、PR の「作成者」は GitHub のアカウント名なので、Slack のアカウント名に変換して Slack で本人にメンションする必要があります。そのため、たまに誤って違うメンバーにメンションをしてしまう問題も発生していました。

これをマージ済み PR の数だけ繰り返す必要があり、リリースタイミングによっては1度に10件を超える事もあります。

改善

事前準備

まず、課題を明確にします。こちらは前述の通りです。

リリース PR 作成時に、マージされた PR の「タイトル」「作成者」を目視で抜き出す事が大変
誤って違うメンバーに動作確認依頼を行ってしまう

次に、その解決方法を調べます。

基本的に手作業で行っていた、マージされた PR の「タイトル」「作成者」を目視で抜き出して作業担当者に依頼する作業を自動化する方針で、かんたんな実装を行いました。これは、次で行う提案のための準備になります。フィードバックの結果、内容を大きく変更する可能性も十分あるため、あまり作り込まず、かつ GO サインをもらえるレベルにします。

KPT での提案

準備した内容をもとに、週1で実施しているウェブチームの KPT で下記の提案をしました。

課題の共有
- リリース作業がツラい
解決案の提示
FAQ
- リリースフローはどう変わるのか
- 導入・運用コスト
- メリットだけではなくデメリットも
- なぜ CI は既存で利用している CircleCI ではなく GitHub Actions で動作させるのか、など

想定していた実装工数は比較的小さいため、一気に導入する手もありますが、次の観点から提案のステップを挟むことにしました。

共通の課題である事の確認および、ニーズの確認
異動や退職などで技術的な負債となる可能性がある
リリースフローの変更により、障害に繋がりやすくなる可能性がある

結果はおおむね期待していた良い反応だったため、具体的な実装に移りました。

変更後

最終的に次の流れになっています。

コードレビューを経て、トピックブランチを master ブランチにマージ（作業者: 各機能担当者）
リリース PR を作成（作業者: リリース担当者）
機能担当者にリリース前テスト環境での動作確認依頼
1. 本文を自動更新 (git-pr-relase gem)
2. GitHub と Slack ID のマッピングを取得 (Apps Script)
3. 動作確認依頼 (Ruby スクリプト)
動作確認（作業者: 各機能担当者）
Jenkins のジョブを実行してリリース（作業者: リリース担当者）

「機能担当者にリリース前テスト環境での動作確認依頼」の作業を自動化しています。

それぞれの技術トピックについてご説明します。

git-pr-release

git-pr-release はリリース PR を作成・更新する gem です。マージされた PR からタイトルや担当者を取得して、PR を作成・更新してくれます。

当初自作をしようと考えていたところ、希望の機能を満たすこちらの gem が見つかり、OSS かつ定期的にメンテナンスされていたため採用しました。

最近 GitHub の仕様変更があり、期待する動作をしなくなる事がありましたが、すぐに対応されたものがリリースされました。

Exclude titles from checklist items by nhosoya · Pull Request #66 · x-motemen/git-pr-release
- タイトルが重複して表示される問題の対応
- PR の本文に #番号 を入力すると自動リンクの仕組みで PR のタイトルも表示されるようになったため
Add nil check for release_pr.body by w1mvy · Pull Request #68 · x-motemen/git-pr-release
- PR 本文を空で作成すると実行が失敗する問題の対応
- 迂回方法として、PR 本文に適当な文字を入力する謎ルールで一時的にしのいでいた

もし自作していた場合、同様の対応を行う可能性が高かったはずです。

Google Apps Script

GitHub アカウント名と Slack ID のマッピングを JOSN として返すウェブアプリケーションサービスです。

次はサービスのURLに対して curl からの擬似的なアクセス例になります。

$ curl -H "Authorization: token xxxx" -L \
  --dump-header - \
  "https://script.google.com/xxxxxx"
(省略)
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
(省略)

[
  {
    "slack_member_id"=>"XXXX",
    "slack_display_name"=>"kyoshida", 
    "github_login_name"=>"kyoshidajp"
  },
  {
    "slack_member_id"=>"YYYY",
    "slack_display_name"=>"yyyy",
    "github_login_name"=>"zzzz"
  },
  ...
]

マージされた PR からその作成者（機能担当者）のアカウント名を取得した後、Slack ID に変換する際にこのマッピング情報を参照します。

事前に Google スプレッドシートにそれぞれの対応を記載しておきます。新しいメンバーが加入したら都度こちらに追加します。このシートのメンテナンスが手動になってしまいますが、他の利用用途でも使えるようになります。