目的
エンティティの提供
観点
- デバッグ
- 逃したバグの早期発見
- 機能改善
- 良い機能をより速く
- DX
- 作業の自動化
評価点
- 時間
- バグ発見コスト
- 顧客価値
- デプロイ待ちの認知負荷
- 労力
リリース先
リリース先によって必要な作業(量)も違う.
- Webアプリ
- GitHub Pages
- remote branchへのpush
- GitHub Pages
リリース、ローンチとどう違うか、どう分けるか
(言葉に酔ってジングピチリオン効果になってはいけない。事実に基づけ)
大枠としては
- 開発からみた"実戦配置"がデプロイ
- ユーザーからみた"機能紹介"がリリース
「hogenized fuga」という機能を配置したら利用可能にはなっているけど、ユーザーからしたら「???」になる.
fugaとは? それがhogenizeされているのか…? hoge...?
機能は使うもの。
使い方、利用例、良さ、などが伝わって初めて意味を成す.
デプロイの最終目的はユーザーへ機能を提供することだが、デプロイだけでは最終目的は達成されない.
ユーザーへの機能告知・developerへの開発ドキュメント公開など、利用するための補助を提供するまでが大事.
リリースはまさにこれ.
press releaseとか、サービスreleaseのお知らせとか、まさに後者.
ということで、デプロイはプログラム配置、リリースはソフトウェアデプロイと機能紹介まで含む
ソフトウェアデプロイ、サービスリリース、がわかりやすい標語になるかな?(動詞には主語をつけろ定期)
CDEへの批判(というか疑問点)として"bizとの連携" "ブランディング戦略" がたまに挙げられる。
機能は「version X、公開」みたいな感じでたまにあるお祭り感を出す必要があるからCDEと合致しない、ステージングまでCDEしてあとはbizが本番デプロイするのがいい、みたいな言説.
サービスリリースをビジネス要件で制御したいという話だけど、上記の通り「hogenized fuga」のデプロイだけなら理解されないのでbiz要件と合致している.
サプライズが!というかもしれないけど、α版によるデバッグとか10/90リリースとかをしてない大手企業なんて珍しいくらい.
hogenized fugaをわざわざ解析して広めてくれる人がいるといい口コミ宣伝になるし、むしろ全体で見てメリットすらありそう.
ソフトウェアCDEがもたらす利点がとても大きいので、基本姿勢/デフォルトでソフトウェア本番CDE、がいいと思う.
追記: 制御強度に合わせてFeature Flag使えば?
タイプ: 概念 | 実装