rights reserved. Blue / Green デプロイ • AWS CodeDeploy, ALB でコントロール • Green タスク群に本番トラフィックを流す前にテストを実施 Blue tasks: v1 code Green tasks: v2 code ALB 100% Prod traffic 100% Test traffic
rights reserved. Blue / Green デプロイ • AWS CodeDeploy, ALB でコントロール • Green タスク群に本番トラフィックを流す前にテストを実施 Green tasks: v2 code ALB 100% Test traffic Blue tasks: v1 code
rights reserved. こういった話を⽿にすることがあります リリース時の起きる障害が多く、⼼配なので 安全な Blue / Green デプロイを採⽤します︕ 破壊的変更を⼊れやすいので、 とりあえず Blue / Green デプロイにします︕ 安全性を損ねている問題の本質と 本当に向き合えているのでしょうか︖ デプロイフロー/プロセスの複雑化が進み、 安全性を損ねる結果につながっていないでしょうか︖
rights reserved. デプロイ関連の問題の⼤半は、 複雑で不安定なデプロイである 1. そもそもソフトウェアを作る段階でデプロイの容易性を 念頭に置いていない 2. ⼿作業による本番環境への変更・追加が デプロイプロセスの⼀部になっている 3. デプロイが複雑なため、 チーム間の作業の引き継ぎが多くなる - 「 L E A N と D E V O P S の 科 学 」 よ り -
rights reserved. 「とりあえず Blue /Green にしておきたい」という思考 • Blue / Green デプロイは安全性が⾼く、多機能なデプロイ戦略 • 「とりあえず Blue /Green にしておきたい」というメンタルモデル に課題がある • 多機能がゆえに、いろんなことをやりたくなり、 結果フローやプロセスの複雑性が増しがち • 今ある課題は本当にデプロイ戦略で解決すべき課題なのか