Google Calendar を活用した Typetalk チームリリース自動化改善

現在 Typetalk チームではリリース作業の多くを自動化し、開発者はリリースボットを呼ぶだけで最新版リリースが完了するようになっています。リリースするまでの流れは以下のようなフローになっていますが、最初からこのような自動化ができていたわけではありません。

Typetalk リリースフロー

リリースにおける課題

今の手軽さに至るまでには以下のような課題があり、プロダクト初期はとくにリリースへの気軽さが欠けていました。

1. リリース準備の面倒さ

プロダクト初期のころは本番環境にリリースするために Git のタグを手動で打ち込み、 Jenkins のリリースジョブをボットから実行する必要がありました。リリースするには手動でバージョンを変更する作業もあってリリース作業に手間がかかっていました。開発者はそれらの作業を自動化するシェルスクリプトを用意してリリースをする状況でした。

2. リリース作業の属人化

これは 1 の課題による影響が大きいですが、リリース作業が特定の人によって行われることが多かったです。大きいリリースをするために普段から細かく分けたり、小さな不具合を修正したりとリリースはそれなりに高い頻度で行なっていました。しかし開発メンバー誰しもが気軽にリリースできる体制になっておらず、リリースする人はリリース準備も含め負担になっていました。

3. リリース内容が把握しづらい

リリースログとして何が含まれてリリースされたのか、あとから気軽に知る手立てがありませんでした。 Git のコマンドを実行すれば前回リリースからの差分を知ることができますが、それを行えるのは開発者に限られます。それらの作業を行い報告する負荷を考えると現実的ではありませんでした。

課題を解決していく

サービス開発は長く続いていき、その中でチームメンバーの構成は変わっていきます。属人化をなくし、後から開発者が入ってもすぐにリリースができる体制にしていかなければいけませんでした。

それらの問題を解決すべく Typetalk チームが定期的におこなっている「ふりかえり」を中心に出た相談、アイデアで以下のような解決を進めていきました。

Jenkins によるリリース自動化

手動で行っていたリリース手順を Jenkins が作業を行い自動化するようにしました。サーバーの入れ替え作業にも課題がありましたが、 AWS Code Deploy によるデプロイ環境整備を中心に改善を別に進めました。最終的には Jenkins のジョブを実行したら後は、新しいバージョンにユーザーのアクセスを切り替えるだけになりました。

Google Calendar にリリースイベントを登録する

手動で行なっていたリリース予定日、時間を開発メンバー全員がみられる Google Calendar に登録するようにしました。定例リリースであれば Google Calendar の繰り返し登録機能を使って一括で登録できます。あとは AWS Lambda から対象リリースイベントを探すようにし、時間になったら Jenkins によるリリースジョブを自動で実行するようにしました。

（実際に行なっているリリースイベントではなくサンプルです）

ジョブの中で後述する Backlog リリース課題を作成し、担当チームメンバーをリリース担当者としてプログラムで順番に割り振るようにしました。リリース時間を変更したかったり、別の曜日、時間にスポットでリリースをしたい場合は、カレンダーのイベントをずらしたり、新たにイベントを追加するだけです。

この自動化により何もせずともリリース前準備が完了するようになりました。 ちょっとしたリリースメモもカレンダーに書き込めることで、チーム全体でリリース概要を把握することもできるようになりました。

Backlog にリリース内容を自動で記載する

Typetalk チームは Git ブランチ名に Backlog の課題キーと課題名を含めた issue-key/issue-name といったかたちで命名するルールをつくっています。リリースする時に Git diff 機能を利用して前回リリースからの main ブランチへのマージコミットをブランチ名を含めたかたちで一覧に出すようにしました。ブランチ名を簡単につけられるよう、英語で記載している課題名をブランチ名にするスクリプトもチームに配布されています。

Backlog リリース課題

この差分を出力した一覧を Backlog の課題にリリース課題として起票し、プロダクトマネージャーに通知します。課題キーには課題へのリンクが自動で貼られるため、ブランチ名で判別できない場合は課題を開くことで内容がわかります。課題作成時には Backlog の通知が行い、 Typetalk への通知も自動で行われることにより、リリース担当者が人に伝えるコストがなくなりました。

Typetalk ボットからリリースする

リリース課題の準備をしている裏では新しいバージョンのサーバーにアクセスを切り替えるだけの状態になっています。リリース内容の確認が取れ、動作確認も取れたところでリリース担当者が Typetalk のトピックにいるリリースボットを叩きます。これによってリリースを行う Jenkins のジョブが実行され、リリース作業が完了します。開発者はただリリースボットを叩くだけでリリースができる手軽さを得ました。

ボットを呼んでリリースを行います

まとめ

問題をひとつひとつ解いていくことで、リリースを小さく定期的に、開発メンバーであればデプロイを行えるようになりました。

これらの改善は一夜にして行えたわけではありません。 SRE チームが中心となって、変わりゆく組織、開発チーム、プロダクトに適したかたちで開発チームと協力しながら改善をし続けた取り組みになります。こうした取り組みを通じてチーム全体でリリースに関して興味を持ち、一緒に改善を行えたこともチームとしてよかったと感じています。

プロダクトのフェーズ、構成、チームによって適切なデプロイの手法や頻度は変わります。今後も私たちはこれらの変化に柔軟に適応し、ユーザーのみなさんに早く継続的にリリースを行い改善していけるようにします。