リリースとは、新しい機能や修正をユーザーが使える状態にすることです。
Web開発では、デプロイと似た言葉として出てきますが、意味は少し違います。
リリースとは
リリースは、ユーザーに変更を届けることです。
たとえば、次のような場面です。
- 新しい機能を公開する
- バグ修正を反映する
- デザイン変更をユーザーに見せる
- アプリの新バージョンを配布する
単にコードをサーバーへ置くだけでなく、ユーザーが使える状態にするところまで含めて考えます。
デプロイとの違い
デプロイは、コードやアプリをサーバーなどの実行環境へ配置することです。
リリースは、ユーザーに公開することです。
| 用語 | 意味 |
|---|---|
| デプロイ | 実行環境へ反映する |
| リリース | ユーザーが使える状態にする |
小さな個人開発では、デプロイとリリースがほぼ同時になることもあります。
なぜ分けて考えるのか
現場では、デプロイしてもすぐ全ユーザーに公開しないことがあります。
たとえば、次のような運用です。
- 管理者だけ先に確認する
- 一部ユーザーだけに公開する
- 機能フラグで切り替える
- 問題があればすぐ戻す
大きなサービスほど、公開のタイミングを慎重に管理します。
リリース前に確認すること
初心者の個人開発でも、公開前に最低限の確認をすると安心です。
- 主要な画面が開けるか
- フォーム送信が動くか
- スマホ表示が崩れていないか
- 不要なテストデータが残っていないか
- READMEや使い方が古くないか
- 環境変数を公開していないか
特に、秘密情報をGitHubへ上げないことは重要です。
ポートフォリオでのリリース
ポートフォリオでは、リリースしただけで終わらせないことが大切です。
READMEに次の情報を書くと、評価されやすくなります。
- 何を作ったか
- どんな課題を解決するか
- 使った技術
- 工夫した点
- 今後改善したい点
「作った」だけでなく、「なぜ作り、どう公開したか」を説明できると強くなります。
同じ日でない例
新機能を月曜日に本番環境へdeployしても、feature flagをOFFにすれば利用者には見えません。水曜日に社内利用者だけへON、金曜日に全員へONにすると、releaseを段階的に行えます。
成功例は、deployの成功確認と、利用者へreleaseする判断・監視・rollback条件を分けることです。失敗例は、fileを配置できただけで利用者の主要操作まで成功したと思うことです。
確認問題
新しいcodeは本番serverにあるがflagがOFFです。deploy済みですが、一般利用者には未releaseです。逆に静的siteではdeployと公開がほぼ同時になる場合もあります。
公開前の確認はリリースチェックリスト、段階的な切り替え例はBlue-Green Deploymentを参照してください。
まとめ
リリースは、機能や修正をユーザーが使える状態にすることです。デプロイは反映作業、リリースは公開の判断を含む言葉として分けて理解しましょう。
← 一覧に戻る
