こんにちは、ソーシャル経済メディア「NewsPicks」の西（@yukinissie）です。

この記事は NewsPicks アドベントカレンダー 2023 の10日目の記事です。

昨日は同僚の田端さんによる『Next.jsプロジェクトの設計改善を進める上で考えていたこと』でした！

「複数チームで1つのシステムにコミットするように開発フェーズが変化したら main にマージした成果物は即リリースするようにフローを変えた方がリリースが楽になるよ！」という話を私が所属しているチームの実体験を元に話します。

WX ユニットのお仕事
フロントエンド基盤について
開発フェーズの定義
改善前の開発フェーズとリリースフローについて
- 改善前の WX ユニットの開発フェーズ
- 改善前の新フロントエンド基盤のリリースフロー
開発フェーズが変化して旧リリースフローの何が問題となったか
リリースフローをどのように変えたことで問題を解決したか
まとめ
告知

WX ユニットのお仕事

少しだけ私の所属しているチーム「Web Experience Unit（以下 WX ユニット）」の話をさせてください。

WX ユニットは「NewsPicks の Web プロダクトのリアーキテクチャを提案」したことをきっかけに2年ほど前にチームが結成され、1からWeb ページのレンダリングに用いている基盤（以下フロントエンド基盤）を4〜6人ほどのエンジニアで作り直してきました。

今でもフロントエンド基盤のリアーキテクチャと Web ページのリニューアルを4人で行っています。

また、SEO や Google Analytics など Web 固有の知識が必要な部分のメンテナンスや、Web アクセシビリティの改善、監視体制、デザインシステムの具現化なども行っています。

フロントエンド基盤について

本題とは直接関係がありませんが、新旧それぞれで用いているフロントエンド基盤のアプリ構成についても簡単に紹介させてください。

旧基盤は、モバイルアプリ向けに開発されたJavaアプリケーションサーバー（Spring Frameworkベース）と同じコアモジュールを利用しつつ以下のような構成でした。

SSRに Thymeleaf や一部 Apache Velocity Engine を利用
スタイリングは CSS と一部 SASS を利用
AltJS として CoffeeScript や jQuery を利用
JavaScript のライブラリ管理に Bower を利用
Node.js ライブラリの管理に npm を利用
JavaScript へのビルドツールとして Grunt の利用

上記構成をやめて、新基盤では以下のような構成にしました。

SSRに Next.js を利用
スタイリングは Emotion を利用
AltJSとして TypeScript を利用
Node.js ライブラリの管理に npm を利用（旧基盤とは別プロジェクト）
Backend for frontend（BFF）としての Apollo Server を配置
Thymeleaf を動かしていたアセットサーバーを廃止してモバイル向けAPIサーバーにリクエストを集約
デザインシステム構築やVRTのために Storybook を導入
単体テストのために Jest を導入

開発フェーズの定義

本記事における開発フェーズとは、1つのシステムに対してコミットするチームの数やリリースしたい成果物の供給量の状態を指します。

SDLCを意識した特定のモデルに基づいたものの1要素ではありません。

例1：複数のチームでできた複数の成果物をガンガンリリースしてユーザーに届けるフェーズ

例2：1つのチームのみで成果物をリリースしており、かつユーザーの目には触れないのでとりあえず Git の main とプロダクションが乖離しない程度にリリースするフェーズ

改善前の開発フェーズとリリースフローについて

改善前の WX ユニットの開発フェーズ

新しいフロントエンド基盤は WX ユニットが最初に作成し、最初の2年ほどはリアーキテクチャ対象となったページの開発も全て WX ユニットが担っていました。リアーキテクチャ対象となったページの例としてはトップページがあり、サービスの顔となるページでもあり、もともとの機能を落とさないように慎重に行われました。

リアーキテクチャと言いつつ、UX改善のための大幅なUI変更も行っているので、いわゆるリニューアルも同時に行われました。

旧基盤から全く別のサーバーアプリケーションとしてフロントエンドのコンテンツを配信する新基盤はpath-based routing（ロードバランサーを利用したページ（URL）単位での公開）で新旧切り替えを行なっているので、ページが完成するまではユーザーに対しては非公開にしていました。

ページで用いるコンポーネント開発は atomic design からヒントを得て小さい部品を先に作り、後から組み合わせる形になっていました。

改善前の新フロントエンド基盤のリリースフロー

1チームしかコミットしていないことや、Organisms レベルのコンポーネントしかできていない開発フェーズでは、リリースをしてもユーザーに届くことはないので、リリースよりも開発することに時間を割きたいという想いの強さから、GitHub Flow を習いつつも main にマージしたら即リリースではなく、週に1度の定期的な予定をいれてプロダクションにデプロイしていました。また、プルリクエストのレビューで承認されたら即 main にマージはしていました。

よって、リリース当番は前回リリースタグから main の差分を確認して動作確認対象を手順書に書いていました。もちろん、リリース直前にも行っていました。

リリース対象のプルリクエストは20件を超えることは珍しくなく、中には40件を超えるものもありました。

リリース予定時間になると、全員が同じテレビ会議に参加して、当番のファシリテーションのもと、自分が担当したプルリクエストのコードが検証環境でも問題なく動作しているかを確認していました。

リリース成果物がないチーム内のメンバーも参加する必要がありました。変更行数が多くE2E環境も十分に整っていない上で、検証環境が壊れていないことを人力で確認する必要があったからです。

ビックバンリリースが常態化していたと言うと少し聞こえが悪いかもしれませんが、その通りでした。

しかし、ページが完成するまではユーザーに公開されないことや開発時間の最大化のためには1チームだけでコミットしている以上は理に叶っていました。（リリース当番の負荷は大きかったです）

改善前の WX ユニットのリリースフローについてまとめると、GitHub Flow に習いつつ main にマージしてもデプロイはせずに開発を優先させ、リリースは週に1度のタイミングで行っていました。

開発フェーズが変化して旧リリースフローの何が問題となったか

トップページを無事にユーザーに公開した頃、WX ユニット以外のチームもリアーキテクチャプロジェクトに参加するようになりました。これはとても喜ばしいことです！

それから、トップページの公開のような大きなリリースをした後によくあることですが、すぐに改善したい部分が出てきました。

1つのシステムに対してコミットするチームの数やリリースしたい成果物の供給量が増えたことを意味しており、開発フェーズが変化したと言えます。

ただし、しばらくはリリースフローを変えませんでした。

するとすぐに問題が起きました。リリースするためには WX ユニット以外のチームメンバーも集める必要がでてきたからです！

なぜなら main にあるソースコードには毎時間ごとに様々なチームがプルリクエストをマージするようになったからです。

コード自体は承認され、デプロイ可能でも、いざプロダクションにデプロイしようとしても、動作確認のために人を集められなければ実質リリースが不可能な状態に陥りました。

例えば火曜日の午後2時ならチャットでメンションをすれば他のチームも動作確認のために呼び集められるかもしれませんが、土曜の夜2時に緊急リリースを予定した際に自身の知らない成果物全てと緊急パッチの全てを素早くリリースすることはシニアエンジニアでも難しいでしょう。少なくとも全員を叩き起こすのは無理です（極端な例ですが）

新フロントエンド基盤のメインメンテナーでない WX ユニット以外のチームならなおさらリリースが難しいでしょう。

リリースフローをどのように変えたことで問題を解決したか

簡単です。main にマージしたら即リリースするようにフローを変えました。

リリースする前にmainとプロダクションのコードが一致していて、リリース作業開始時にはリリース担当者がコードの内容を簡単に把握しているものだけをプルリクエストからmainにマージし、それをその場でリリースしてもらう方式に変えました。

これは、GitHub Flowを説明しているScott Chacon氏の6つ目のルール「#6 - deploy immediately after review（GitHub Flowより）」を実践したものです。

フローを変えたことにより、WX ユニットに限らずさまざまなチームが独立して任意のタイミングでリリース作業に取り組むことができ、動作確認のために他チームを呼ぶ必要も待つ必要もなくなり、リリースが楽になりました。

まとめ

開発フェーズによっては最適だったかもしれないリリースフローもフェーズが変われば辛い状態になることもあります。今回はGitHub Flowに正しく基づくことによって現状のリリースフローの最適解を見つけましたが、どの開発プロジェクトのどの開発フェーズにでも適用できるとも思えないので、今後も開発に関わるメンバーとコミュニケーションを取りつつ快適な開発現場を作っていきたいと思いました。

長い前説とともにここまで読んでいただきありがとうございました！力尽きてしまいました。。