LIPSの技術スタック・開発フロー（サーバーサイド編）

（この記事は2024年4月に弊社Zennに掲載した内容となっております）。

LIPSはリリースから7年を経て1100万DLを超える美容やコスメのプラットフォーム・コミュニティサービスです。継続的な開発と長期的な運用を視野に入れ、生産性や開発体験を高い水準に保ち続けられるよう、AppBrewでは開発環境を継続的に改善し続けています。
この記事では、LIPSの技術スタックや開発の流れについて、特にサーバーサイドを中心に紹介します。技術スタック、開発環境、コーディングガイドライン、テスト、レビュー、CI/CD など、ソフトウェア開発者が日々実際に使っている技術的な要素とそこでの工夫を順に紹介します。

LIPSの技術スタック

LIPSで採用している主な技術要素は上のものです。
そのうち、特にサーバーサイド開発者が普段の開発で日々触れることになるのは以下のものです：

• サーバーサイド開発：Ruby, Ruby on Rails, GraphQL
• データベース：MySQL, Elasticsearch, Redis
• データ活用：redash, dbt
• コミュニケーション：GitHub, Notion, Slack, Figma
• CI/CD：CircleCI, GitHub Actions
• モニタリング：Datadog, BugSnag

今回はRuby, Railsを中心にLIPSのバックエンド開発のフローに沿って取り組んでいることをご紹介したいと思います。

コーディングと実装環境

Ruby, Railsは最新バージョンを比較的早めに追いかけています。2024年3月1日の時点でRubyのバージョンは 3.2.2、Railsのバージョンは 7.1.2 です。

LIPSは国内のこの領域で最大のサービスになりつつあります。
立ち上げ期のサービスではライブラリ更新等後回しが妥当なこともありますが、LIPSは継続的な運用を見据えるべきフェイズなので、基本的に都度更新していく方針です。

Gemの更新はdependabotで管理しています。
定期的にサーバーサイドエンジニアが集まってアップデート会を開催し、優先度を決めたりリスクを洗い出したりしながら進めています。

コーディングにおいては、独自で定めているRailsのコーディングガイドラインがあるので、それに沿って各自で実装を行っています。
弊社では業務委託のr7kamuraさん中心に整備を進めており、rubocopで自動指摘できないところはこちらのコーディングガイドラインをもとにレビューを行うことでコードの健全性を保つように心がけています。

実際のガイドラインはこちらです

弊社にはサービスのデータベースを Slack や GitHub のコマンドで複製できる仕組みがあります。

実際自分用のデータベースを気軽に作って開発に使っていて、本番に近いデータを使うことで、実際のユーザー体験を確認しながら開発したり、アルゴリズムの速度や品質の問題に早い段階で気付けるなどのメリットを享受しています。

実際この仕組みを構築する上では、センシティブなデータのマスキングやデータベース複製のパフォーマンスなど技術的に解決すべき課題がいくつかありました。詳しくは以下の記事で紹介しています。

テスト

テストフレームワークとしてはRSpecを使っています。
エンドポイントのテストとロジックのテストは基本的には書く文化があります。テストの程度は各自に任されている印象ですが、どのくらいテストを書くべきかという話になるとアジャイルサムライという本にある「危なっかしいところをすべてテストする」という方針をCTOは推奨しているようです。

また、テストコード自体の可読性を維持するための仕組みとして、前述のコードガイドラインとそれに基づいたrubocopのルールを導入し、可読性の高いテストコードを誰でもかけるように工夫しています。

レビュー

サーバーサイドのレポジトリではブランチ戦略としてGit Feature Flowを採用しています。

弊社には、git ブランチから検証用の環境を構築できる仕組みがあります。

GitHub上でコマンドを入力すると、以下の流れで指定したプルリクエストに対応する検証用の環境が10分ほどで利用可能になります。これを活用し、開発者ではない人にも開発中の機能を気軽にレビューしてもらうことができます。

デプロイフロー

弊社では開発ブランチ、本番ブランチが変更されると検証用環境、本番環境が自動で再構築されます。
開発者はひとまとまりの開発を終えると、その変更を開発ブランチにマージします。そうするとテストや静的解析、デプロイなどがCIシステム上で実行されます。
具体的には以下のような処理が CI システム上で実行されています。

この中で、"slim-lint"と呼ばれるチェックでは、r7kamuraさんが開発したslimcopというGemを使用してSlimテンプレートの検査が行われます。このgemは、auto-correct機能に対応しており、Slimテンプレートで指摘された違反を手作業ではなく自動的に修正することができます。slimcopに関する詳細は、以下の記事をご参照ください。

また、PR-Agentと呼ばれる、ChatGPTを活用してPull Requestの自動レビューや変更のサマリを自動的に作成してくれます。これにより、レビュアーがより効果的にレビューを行える環境が整えられています。

おわりに

この記事ではLIPSのサーバーサイド開発に焦点を当て、技術スタックや開発の流れ、開発の工夫について紹介しました。
弊社では事業成長のための機能開発だけでなく、サービスのスケールに伴うシステムや開発フローの複雑化に対処し、開発者の生産性を高く保つための基盤作りにもチームを分けず継続的に取り組んでいます。プロダクトの成長とより良い開発者環境作りの両面にチャレンジしたい方は楽しんでいただける環境なのではないかと思います。
ぜひお気軽にお話聞きに来てください！