Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

Dev container化による環境構築の改善の取り組み

Eight Rails

外に出るとくたばってしまうほどの暑さで、ネックファンと日傘がないと生きていけない日が続いていますが、皆さんはどうお過ごしでしょうか？

どうも技術本部Eight Engineering Unit Product Devグループの平石です。
今回はEightの開発環境構築の体験改善のために行ったDev container化についてお話しします。

背景

EightのサーバーサイドはRuby on Railsで開発を行っており、長らくエンジニアはローカルでの開発環境構築を推奨していました。一方でローカルに構築する上でプロダクトの関係上、依存するpackageも多く、ドキュメント化されてはいるもののbundle installでつまずくなどすんなりと開発に入れることは多くありませんでした。

そのため、新メンバーが参加する際や、既存メンバーのPC交換等で新しく環境構築をする際はだいぶ時間を使っていました。
また、うまく行かない場合にシニアメンバーに助けを求めることも多く、サポートする人もそこそこの工数を環境構築に費やしていました。

Step1: Docker化による環境統一

この課題を解決するために、ローカルのRails環境をDocker化する取り組みを始めました。Dockerを用いることで、環境の統一が図られ環境構築にかかる時間を大幅に削減されることが期待されました。

一方ですでにローカルでRails環境を構築しているメンバーにとっては不要なコンテナになるため、profileを使って必要なメンバーのみコンテナを作るという運用としました。

docs.docker.jp

Docker上にRailsを構築した開発の非効率さ

しかし、Docker上で環境を構築した結果、Ruby LSP や Rubocop などの拡張機能がローカルのVSCodeで機能しないため、サジェストや定義ジャンプ、コード規則違反の指摘が表示されない等の問題が発生しました。これでは開発者体験の向上にはつながらず、再度の見直しが必要となりました。

Step2: Dev containerの導入

Docker化で発生した開発者体験の問題を解消するために、Dev containerを使うことにしました。

Dev containerとは

Dev containerはVSCodeの開発環境構築支援ツールでDockerとVSCodeさえあれば利用できます。（Dockerなので ホストのOSにこだわらない）Dockerコンテナ内にVSCodeのサーバを建ててローカルのVSCodeと通信をしてコーディングできるので、Docker上に構築したものと同様ローカル環境を汚染することなく開発できます。

code.visualstudio.com


Dev containerではdevcontainer.jsonにVSCodeの設定や拡張機能を定義できるため、各エンジニアにおいての開発環境の共通化が可能になります。

{
  ...
  "customizations": {
    "vscode": {
      "extensions": [
        "Shopify.ruby-lsp",
        "rubocop.vscode-rubocop",
      ],
      "settings": {
        "rubyLsp.bundleGemfile": "Gemfile",
        "rubyLsp.formatter": "auto",
        "[ruby]": {
          "editor.defaultFormatter": "Shopify.ruby-lsp",
          "editor.formatOnSave": true
        },
      }
    }
  }
}

上記のようにdevcontainer.jsonに記載して接続すれば、追加で開発者が拡張機能を追加でインストールしたり、設定をいじったりする必要なく、サジェストや定義ジャンプ、コード規則違反による指摘が表示されるようになりました。

開発環境のDev container化に伴って発生したこと

Eightの開発ではLefthookを使ったcommit前のlint checkを行っているのですが（参考）、Dev containerによって環境構築していない場合ローカルにRails環境を構築していないためlint checkが実行できずcommitが通らないという問題が発生しました。
no-verifyオプションをつければcommitすることは可能ですが、推奨することはできません。またlint checkコマンドをコンテナ上で実行するというのことも考えましたが、Dev containerを構築していないメンバーにとっては追加で構築する必要があります。
最終的に、Git Hooksの中でRailsのコンテナの有無をチェックし、コンテナが存在する場合はコンテナ内でlint checkコマンドを実行、存在しない場合はローカルでコマンドを実行するという形にスクリプトを変更しました。

buildersbox.corp-sansan.com

まとめ

Dev container化による環境構築の改善は、非常に簡単に構築でき、かつ環境設定を半強制的に統一させられるため拡張機能やエディタの設定の共有などをする必要がなくなります。また、環境構築のドキュメントの内容も非常に少なくなるためメンテも非常に楽になっています。
環境構築にかかるコストはEightにとって長年課題となっていたことであり、これによって今後Eightで新たなエンジニアメンバーを受け入れる際においてスムーズに開発に取り組み始めることができ、既存メンバーへの対応工数も削減されました。

Eightでは今後も開発者体験に関わる改善を進め、生産性向上に向き合っていきます！

media.sansan-engineering.com

© Sansan, Inc.