Webフロントエンドのリリース戦略
Webフロントエンドのリリースをどうするのか
前置き
Web開発に分業化が進み、Webフロントエンドの開発は独自に行われることが多くなった。
しかし、Webフロントエンドのリソースの配信はサーバサイドが絡むことも多く、Webフロントエンドに取って最適な方法が取られているとはいえない場合も多い。
ここでは、主にiOS, Androidアプリなどのリリース方法を参考にWebフロントエンドのリソースの配信（リリース）をどうするかを書く。
Webフロントエンド特有の事情
iOS, Androidアプリの場合、リリースに関しては事実上プラットフォームから指定されているため選択肢が少ない。
しかし、Webフロントエンドの場合、事実上URLで指定できる場所にさえおければリリース処理が終わることが多く、自由度が高い。
前提
ここで言う「Webフロントエンド」とは、「Webアプリケーション」と言われるようなそれなりにコード量の多いものを想定している。
Webフロントエンドのリリース戦略とは
以下のようなリリース戦略を提案する。
developへmerge時にフロントエンドチームへリリース
平日17時にdevelopを開発チームリリース
平日10時にdevelopをmainへmerge
平日14時から1時間ごとにmainを段階リリース
平日17時にmainを全体へリリースする
上記の「平日」は祝日を考慮し、休日の前日は除外する方が良い。 （Google Calendar APIから取得するとメンテナンスコストが低くて良い）
もし課金サービスであるなら、段階リリースは非課金ユーザに対して行うことが望ましい。 （Sentry等でエラー監視を行う場合、段階リリース対象のユーザのエラーに注意すること）
時間はあくまでも参考なので、主な業務時間に合わせて調整する。 （上記は主にtoBの場合を想定している）
もし、各段階で障害が発覚した場合、develop -> mainの順で修正し、リリースを行い直す。
コンセプト
重要なのは以下の点。
リリースは自動であること ただし、障害発生時の対応のため、手動でリリーする方法も確保すること
段階的にリリースされること
上記の例の場合、以下の順番でリリースされる
主な開発者（問題があった場合自分で修正できる者）
開発者全体（エラーがあっても対処できる者）
段階リリース対象者
全ユーザ
リリース段階に社内の非開発者を対象とすることは推奨しない （ユーザサポート等でユーザと環境が違った場合に支障が出やすいため）
まとめ
主にWebフロントエンドを対象としたリリース戦略を書いた。
上記はリリース戦略はWebフロントエンドに限らないが、Webフロントエンドの場合リリースにあたりDB等の状態を考慮する必要が低いためリリース戦略の自由度が高い。
過去、実際に上記のリリースフローで運用したが、考慮事項が少なくドキュメントも少なかった。
