顧客にすばやく価値を届けるために、開発から運用への作業の流れを早くスムースにする

作業を可視化し、バッチサイズを縮小し、作業のインターバルを短縮し、品質を組み込んで下流に不良品が流れないようにする

やるべきこと

作業の可視化

IT のバリューストリームと生産のバリューストリームの大きな違いは、IT のバリューストリームは目に見えないこと

できるだけ可視化するために、カンバンボードやスプリント計画ボードを使う

バッチサイズの縮小

受け渡しの回数を制限する

絶えず制約条件 (ボトルネック) を見つけ出して尊重する (制約条件の理論)

DevOps 改革の中では、一般的に制約条件は次のように変わっていく

1. 環境の作成

2. コードのデプロイ

3. テストの準備と実行

4. 過度に密結合なアーキテクチャ

バリューストリームからムダと苦痛を取り除く

部分的に完成した仕事、余分な処理、余分な機能、タスク切り替え、待機、動作、不良、非標準的な作業や手作業、超人的な作業

継続的デリバリーと呼ばれる一連の技術的実践の話

バージョン管理システムに格納されているものをもとに、完全な本番環境を再現することが目標

バージョン管理システムは、デベロッパーだけでなく、QA、運用、情報セキュリティを含むバリューストリーム内の全員が使わなければならない

「2014 State of DevOps Report」 によると、運用がバージョン管理システムを使っているかどうかが IT のパフォーマンスと会社全体の業績の両方の重要な予測因子

再構築が容易なインフラストラクチャを作る

本番環境を手作業で変更することを禁止して、コードの変更により本番環境に反映するように

開発の完成の定義を、「本番環境に近い環境で予定通りに動作することを確認する」 こととする

一般に、自動テストは高速なものから次のように分類される

自動パフォーマンステストや非機能要件テストもデプロイパイプラインの中で実施

Infrastructure as Code の構成管理ツールを使えば、コードをテストするのと同じテストフレームワークで、環境の構成や設定もテストできる

アプリケーションに対する分析ツールと同じように、環境を構成するコードに対する分析も実施 (Chef の Foodcritic や Puppet の puppet-lint)

セキュリティハードニングチェックも (Serverspec など)

デプロイパイプラインが壊れたらアンドンの紐をひく

継続的インテグレーションは、ブランチをトランクにマージすることの困難を解消する

継続的インテグレーションとトランクベースの開発

デプロイプロセスの自働化 : 既存のプロセスをドキュメント化し、それを単純化し、自動化する

デプロイとリリースを独立させる

これらを独立させることで、開発と運用は速くて頻繁なデプロイの責任、製品オーナーはリリースをビジネスとして成功させる責任をそれぞれ負うことができる

リリースのパターンは 2 つ

環境ベースのリリース : トラフィックを環境で切り替えてリリース

ブルーグリーンデプロイメントやカナリアリリース、クラスターイミューンシステムなど

アプリケーションベースのリリース : 小さな設定変更で選択的にアプリケーションの機能をリリース

機能トグルなど

ダークローンチを実現できる

継続的デリバリーと継続的デプロイ

アーキテクチャをどう移行するか？

eBay では、小さなパイロットプロジェクトで問題理解を自身に示して、それから書き換えに踏み込む

Shoup チームでは、絞め殺しアプリケーションパターン (strangler application pattern) と呼ばれるテクニックを使用した

企業が製品ライフサイクルの初期にいるときはモノリシックなアーキテクチャが最良である場合も多い

やがてモノリシックアーキテクチャが足かせになり、サービス指向アーキテクチャに移行 (Amazon の例)