> ## Documentation Index
> Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.
# リリース
> コードのデプロイと機能のリリースを分離する考え方を解説します。環境変数ベースのFeature Flag、トランクベース開発、段階的ロールアウト、即時の切り戻し、フラグの掃除を扱います。
## 概要
リリースとは、コードが本番環境に届くタイミングとは独立に、変更をいつ・どのようにユーザーへ見せるかを決める一連の判断です。核となる原則は「デプロイ」と「リリース」の分離です。デプロイはコードを本番環境へ反映する機械的な作業であり、リリースは機能を公開するという判断です。
本ページではこの分離の考え方、それを実装するFeature Flagの仕組み、トランクベース開発との関係、そして安全なロールアウト・切り戻し・フラグの掃除までを解説します。
デプロイ自体を自動化するパイプラインは[CI/CD](/ja/development/ci-cd)のページで扱い、本ページは「いつユーザーに見せるか」の判断と手法を扱います。
## デプロイとリリースは別の出来事
コードのデプロイと機能のリリースは同じ瞬間に起こることが多いものの、答える問いも、判断の主体も異なります。
コードを本番環境へ反映することです。自動化でき、1日に何度でも実行できる、機械的で反復可能なステップです。
機能をユーザーが使える状態にすることです。告知やサポート体制、ビジネス上の節目との調整を含む、タイミングの判断です。
この2つを結合したままにすると、トレードオフを強いられます。デプロイが公開タイミングを待つなら変更が溜まって大きくリスクの高いバッチになり、コードの到達と同時に機能が公開されるなら準備が整っていなくても公開されてしまいます。
両者の分離は継続的デリバリーの土台です。ソフトウェアを常にリリース可能な状態に保ち、小さな変更を高頻度でデプロイし、リリースのタイミングを意図して選びます。小さく頻繁なデプロイは、個々の変更のレビュー・テスト・取り消しを容易にするため、速度と安定性を同時に高めます。
## Feature Flag
Feature Flagは、コードを変更せずに振る舞いのオン・オフを切り替える条件分岐です。最もシンプルで確実な実装は、コード内の1箇所の分岐点で環境変数を読むことです。
次の例では、環境変数`FEATURE_NEW_LABEL`が`'true'`のときだけ新しいラベルを表示します。ローカル環境でのみ有効にして実装を進め、本番環境では無効のままマージします。
```tsx React theme={null}
export const SampleComponent = () => {
const isEnabledNewLabel = process.env.FEATURE_NEW_LABEL === 'true';
return (
{isEnabledNewLabel && NEW}
Sample
);
};
```
```ruby Ruby theme={null}
def new_label_enabled?
ENV['FEATURE_NEW_LABEL'] == 'true'
end
def sample_labels
labels = []
labels << 'NEW' if new_label_enabled?
labels << 'Sample'
labels.join(' ')
end
```
本番環境での機能の有効化は環境設定への`FEATURE_NEW_LABEL=true`の追加という設定変更であり、無効化はその行を取り除くだけです。
フラグによって「コードが本番環境にある」ことと「機能が見えている」ことが独立した事実になります。これにより次が可能になります。
開発途中の機能をフラグの裏に隠したままメインブランチへマージできます。長命なブランチで寝かせる必要がありません。
1日に何度も本番環境へデプロイしながら、各機能をいつリリースするかを選べます。
リリース済みの機能に問題があればフラグをオフにするだけです。復旧にかかる時間は軽微です。
検証環境や社内利用でだけ先に有効化し、本番環境のユーザーには従来の挙動を見せたまま確認できます。
環境変数ベースのフラグは追加のインフラ無しで実現できるため、はじめの一歩としてはオススメです。フラグ管理のライブラリやサービスの導入を検討するのもいいでしょう。
## トランクベース開発
トランクベース開発は、すべての作業を小さな単位でメインブランチへ統合し続け、数日から数週間生き続けるブランチを避けるプラクティスです。長命なブランチはconflictを蓄積し、統合の問題を最後まで隠し、レビューしにくい大きなプルリクエストを生みます。
複数のプルリクエストにまたがる機能でこれを成立させるのがFeature Flagです。各増分はレビューを通過し次第フラグに守られてマージされ、最後のピースが揃ったときに初めて機能を有効化します。
結果として、同じ領域を複数人で開発してもconflictが起きにくく、すべてのマージが適切にレビューできる大きさに保たれます。
次の図では、1つの機能を3つの増分に分け、それぞれフラグをオフにしたままbaseブランチへマージし、最後の増分がマージされた後にフラグをオンにしてリリースしています。
```mermaid theme={null}
%%{init: {'gitGraph': {'mainBranchName': 'base'}}}%%
gitGraph
commit id: "リリース済み"
branch increment-1
commit id: "実装①（フラグOFF）"
checkout base
merge increment-1 id: "PR: マージ①"
branch increment-2
commit id: "実装②（フラグOFF）"
checkout base
merge increment-2 id: "PR: マージ②"
branch increment-3
commit id: "実装③（フラグOFF）"
checkout base
merge increment-3 id: "PR: マージ③"
commit id: "フラグONでリリース"
```
これは作業を小さな単位に分割する原則と同じ考え方です。作業の切り方は[タスク分解](/ja/development/task-breakdown)を、個々のマージをレビュー可能に保つ方法は[プルリクエスト](/ja/development/pull-request)を参照してください。
## topic branch運用で本番環境への影響を切り離す
フラグの裏に隠せない変更もあります。画面全体の刷新やフレームワークの移行のように、本番環境への影響を隠すことが出来ない場合です。
topic branch運用は、そうした変更でも粒度を維持するための、baseブランチと作業ブランチの間にtopic branchを挟む3層のブランチ構成です。レビューと統合はtopic branch上で完結し、baseブランチにはリリースまで変更が反映されないため、本番環境に影響を与えずに小さなプルリクエストを出し続けられます。
```mermaid theme={null}
%%{init: {'gitGraph': {'mainBranchName': 'base'}}}%%
gitGraph
commit id: "リリース済み"
branch topic
branch develop-1
commit id: "実装①"
checkout topic
merge develop-1 id: "PR: レビュー①"
branch develop-2
commit id: "実装②"
checkout topic
merge develop-2 id: "PR: レビュー②"
checkout base
commit id: "他の変更"
checkout topic
merge base id: "1日1回取り込む"
checkout base
merge topic id: "PR: リリース"
```
運用の流れは次のとおりです。
1. baseブランチからtopic branchを切り、そこからさらに作業用のdevelop branchを切ります。
2. develop branchからtopic branchへのプルリクエストでレビューします。粒度を維持するのはこの段階です。
3. 本番環境への反映の準備が整ったら、topic branchからbaseブランチへのプルリクエストをマージします。このタイミングのレビューは必要最低限で問題ありません。手順2で既にレビュー済みだからです。
4. baseブランチの修正内容は最低1日1回はtopic branchへ取り込み、conflictを最小限に抑えます。
トレードオフは、topic branch自体がリリースまで生き続ける長命なブランチである点です。baseブランチとの統合が後ろ倒しになるのはトランクベース開発が避けようとすることそのものであり、手順4の毎日の取り込みがconflictを管理可能に保つ前提になります。
フラグの裏に隠せる変更ではFeature Flagを優先し、隠せない変更にtopic branch運用を使います。
## 段階的ロールアウトと切り戻し
デプロイとリリースが分離されていると、リリースは一度きりのイベントではなく、制御された一連のステップになります。
コードは無効化された状態で本番環境に到達します。ユーザーには何の変化も見えず、デプロイ自体のリリースリスクはほぼゼロです。
まず検証環境でフラグをオンにします。ユーザーに公開される前に問題が表面化し、欠陥は早く見つかるほど修正コストが小さくなります。
選んだタイミングで本番環境のフラグをオンにします。公開範囲を絞れる場合は、特定のユーザーから展開を始め、徐々に公開範囲を広げます。
機能に問題があればフラグを無効化します。
フラグによる切り戻しが機能するのは、従来のコードパスが残っていて、そのテストが通り続けている場合だけです。フラグが有効な間は、フォールバック側のパスを削除したり壊したりしてはいけません。
## 両方の状態をテストし、フラグを削除する
フラグはコードが取りうる状態を2倍にし、機能のライフサイクルのどこかで両方の状態が本番環境で動きます。分岐の両側にテストを書きます。
```tsx theme={null}
it('FEATURE_NEW_LABELがtrueのときNEWラベルを表示する', () => { /* ... */ })
it('FEATURE_NEW_LABELがfalseのときNEWラベルを表示しない', () => { /* ... */ })
```
オフ側のテストは省略できません。機能の開発が進んでも切り戻し先が動き続けることを保証するのがこのテストです。信頼できるテストの条件は[テストコード](/ja/development/testing)を参照してください。
フラグは設計上、一時的な存在です。フラグをオンにした状態で安定稼働し、オフに戻すシナリオがなくなったら、フラグ・不要になった分岐・オフ側のテストを1つのプルリクエストでまとめて削除します。
放置されたフラグは、誰もテストしていない状態の組み合わせとして積み上がります。信頼できるテストスイートがあるからこそ、この削除を先送りせずに実行できます。
## 関連ページ
フラグの裏でマージできる大きさまで機能を分割します。
個々のマージを小さくレビュー可能に保ちます。
フラグの両状態を守り、フラグの削除を安全にするテストです。