読書メーターのデプロイの流れについて

エンジニア 読書メーター テックブログ

こんにちは。

メディアサービス開発部Webアプリケーション開発課の中野です。

読書メーターのインフラおよびバックエンドシステムを担当しています。

本記事では読書メーターのデプロイの流れについて紹介いたします。

 

読書メーターについて

読書メーターは、2008年5月に開設された日本最大級の読書コミュニティサイトです。

単純な読書記録や感想投稿に留まらず、ユーザ間で交流ができることが特徴的な点です。

読書メーターのインフラ構成

以前、弊社のフサギコ(髙﨑)が読書メーターのインフラ構成について紹介いたしました。

developers.bookwalker.jp

読書メーターは下記の6つのコンポーネントから構成されています。

  • フロントエンドサーバ群
    • Webフロントエンド(Ruby on Rails)
    • スマートフォンアプリ向けAPI(Ruby on Rails)
    • 管理画面(Ruby on Rails)
  • バックエンドサーバ群
    • バックエンド(Scala, Play framework)
    • サブバックエンド(Ruby, Grape)
    • 旧環境(PHP)

上記記事からコンポーネントの構成は変わっていません。

しかし、旧環境(PHP)以外の実行環境に関しては、全てecspressoでデプロイしECS(Fargate)で実行する仕組みに変わりました。

コード管理とブランチ戦略について

読書メーターチームではGitHubでコード管理を行っています。

また、現在1日に数回程度の頻度でデプロイを行うため、ブランチ戦略としてGitHub Flowを採用しています。

デプロイシステム構成について

読書メーターにおけるデプロイの流れとしては以下のようになっています。

  1. Pull Requestをmasterブランチにmerge
  2. GitHub Actionsで「リリース準備」アクションを実行するとGitHubのレポジトリにtag pushされる
  3. tag pushにhookし、CircleCIがイメージを作成してAmazonECRにpushする
  4. CircleCIがescpressoを利用して開発環境のECS(Fargate)にデプロイする
  5. CircleCIがSlackで開発環境にデプロイされたことを通知する
  6. 開発環境で動作確認し、問題なければCircleCI上で本番環境へのデプロイ承認ボタン*1を押す
  7. CircleCIがescpressoを利用して本番環境のECS(Fargate)にデプロイする
  8. CircleCIがSlackで本番環境にデプロイされたことを通知する

これをフロー図としてまとめると以下のようになります。

読書メーターのデプロイフロー図

Github ActionsとCircleCIを併用している理由としては2点あり、1点目は課としてCircleCIをGitHub Actionsより先に導入していたためtag push周り以外はそのまま設定を流用できた事、2点目は、GitHubのプランがTeamプランな都合上、GitHub Actionsでデプロイの承認待ちを実現するGitHub Environmentsの機能が利用できなかったことが挙げられます。

現在エンジニア3人体制で開発を行っていますが、このデプロイフローでデプロイにかかる時間は1回あたり平均16.7分で、デプロイ回数は週平均5回程度行えています。

まとめ

この記事では現在の読書メーターのデプロイの流れについて概観しました。

ブックウォーカーでは物理・電子・Web連載問わず漫画や本が好き、あるいは長年運用されてきたWebサービスを紐解き、より良い形に作り替えていくことに興味があるWebアプリケーションエンジニアを募集しています。

もし興味がありましたらぜひ、ブックウォーカーの採用情報ページからご応募ください。

 

 

 

*1:承認待ちの仕組みはcircleci/slack orbの機能を利用しています。