この記事は、 Mercari Bold Challenge Monthの10日目の記事です。
Mercari JP Web チームフロントエンドエンジニアの nekobato です。
JP Web チームでは、現在 Re-architecture のプロジェクトが進行中です。
先週実はトップページが新しいアーキテクチャに置き換わりました。
また、JP 全体で microservice 化も絶賛進行中であり、同時並行で microservice 化におけるインフラストラクチャの管理を JP Web チームで行っています。
今回は、JP Web チーム内で発足していた Web DevOps チームという小さなチームで行っていた取り組みをご紹介します。
Web DevOps チームとは
Mercari Web JP チームは歴史的には元フロントエンドチーム + α のチームです。
ですのでそのまま microservice に移行しつつ Re-architecture を行うとなると、持ちうる知見の少なさが障害となっていました。
インフラからフロントエンドまでの DevOps の仕組みを片手間で構築するにはラーニングコストが多すぎます。
新しいアーキテクチャによる機能開発とマイクロサービスの管理の構築を同時並行で進めるため、Web JP チームは内部に DevOps チームという小さなチームを作りました。
Web DevOps は、Re-architecture をリリース可能な状態に持っていくまで、専任で知識を吸収して DevOps が可能な環境を作るためのチームです。
ちなみに、Web DevOps チームは Web のファーストリリースが完了したため、めでたく先週解散しました。
Web DevOps チームによる環境構築
基本的に DevOps チームは SRE のようにチーム単体がメンテナンスを続けることを目的とはしておらず、JP Web チーム全体でメンテしていくことが最終目標です。
そのため、環境構築とルールの明文化、そしてメンテナンスのためのドキュメントはセットで作ることを心がけています。
今回はいくつかの例として、Pull Request に対して CircleCI で構築した自動化の例を挙げます。
DevTools
DevOps では以下のようなツールを Pull Request(以下 PR)で実行しています。
Storybook の自動デプロイ
JP Web チームではStorybookと @storybook/addon-storyshots を利用して各コンポーネントの Unit テストを行っています。
開発者が PR を作ると、Storybook は CI 上でコミット毎にバンドルされ、S3 へアップロード完了すると PR へバンドルされた Storybook の URL が通知されます。
アップロードされた Storybook はhttps://[internal web domain]/[procjet name]/[PR number]/storybookから閲覧できます。
当初はコミット毎に PR へ書き込みしてしまい、会話が流れてしまう問題がありました。
現在は CircleCI の環境で生成した足跡ファイルの存在の有無を検出し、二度のコミットからはコメントがスキップされるよう改善されています。
Bundle Analyzer の自動デプロイ
webpack-bundle-analyzerを利用して各 PR のスレッドで実行されます。
webpack-bundle-analyzer はバンドルされた JavaScript が持つ modules サイズがビジュアライズされた html ファイルを生成することができるため、Storybook と同じく S3 へ配置されます。
こちらも Storybook と同じように https://[internal web domain]/[procjet name]/[pull request number]/
Module License Checker の自動実行
NPM module には少数ですが商用不可能なものもあり、それが依存ツリーの中に含まれているかどうかを目視で確認するのは非常に困難です。
Mercari 内製でnlfを利用した NPM modules のライセンスチェッカーがあります。
利用している全ての NPM modules から商用利用可能なライセンスかどうかを判定し、利用不可能なものがあれば CI エラーを返します。
ちなみに package.json にライセンスの記述を持たないモジュールも多く、そういう場合はライセンスチェッカーがエラーを返すため、人の目で README などに書かれているライセンスを確認後、無視リストに追加する運用です。これはしょうがないですね。
Vulnerability Checker の定期実行
同じく Mercari 内製でこちらは NPM modules の脆弱性をチェックしてくれるツールです。
一日一度、 CircleCI の cron で動かしており、脆弱性が検出されれば Slack に通知されます。
脆弱性の通知が届いた場合、On-Call 担当が 修正する変更を適用するルールで運用しています。
Conclusion
今回は Web JP チームには DevOps チームという小さいチームがあり、DevOps の環境構築を専任で行っていたという紹介をしました。
DevOps チームで行ってきた業務の技術的な話は他のメンバーが書いてくれるはずです。
本来 DevOps はその名の通り Developers が Operations を行うためのものですので、DevOps チームとしては Web チームの開発者全員が DevOps 業務の知識を獲得し、行えるようにするのが最終目標です。
そこに至るまでの初期設定やスクリプトの記述、知識の蓄積を専任して行うことで、アプリ機能の実装と堅牢な DevOps 環境を並行して構築することができました。
Next actions
Web Re-architecture はファーストリリースを迎えたため解散しましたが、今後は DevOps を JP Web チームの開発者全員で行えるように知識の拡散を行う必要があります。
今後も元 DevOps チームのメンバーは Web チーム全体へ知識を拡散するために、以下の活動を行っていきます。
- DevOps が今まで行ってきた Ops 環境改善業務は On-Call 担当が行えるようにする
- Kubernetes の変更なども（元 DevOps チームのヘルプを受けながら）開発者がタスクごとに行えるようにする
次の記事は、@sters9 による「INT 32 障害とその BOLD な対策」です。 お楽しみに！
