今回は、DevOpsについて次の観点で説明します。
DevOpsとは
DevOps（Development and Operations）は、ソフトウェア開発（Dev）とIT運用（Ops）を統合する方法論や文化を指します。
DevOpsの主な目的は、ソフトウェアのリリースサイクルを短縮し、高品質のソフトウェアを迅速に提供することです。
これには、開発チームと運用チームの連携を強化し、コミュニケーションとコラボレーションを促進することが含まれます。
DevOpsのプロセスは、継続的デリバリに、継続的モニタリング（ パフォーマンス、セキュリティ、および可用性の監視）と、その結果を継続的に開発にフィードバックするプロセスを加えたものになります。
次の図は、DevOpsのイメージを表したものです。
これを見ると、DevOpsのコアにあるのは継続的デリバリであることがわかります。
継続的デリバリ
ソフトウェア開発で重要なのは、ソフトウェアの変更が必要だと判断してから、それを本番環境で使えるようになるまでのサイクルタイム、つまり、アイデアが実際のビジネス的価値になるまでの時間をいかに短くするかです。
なぜなら、ソフトウェアというものは、ユーザーの手に渡る（デリバリされる）までは何の価値も生み出さないからです。
ソフトウェアの変更が必要だと判断してから、それを本番環境で使えるようになるまでのプロセス（デプロイメントパイプライン）をできるだけ自動化して継続的にユーザーにデリバリできるようにするためのソリューションを継続的デリバリーといいます。
次に、継続的デリバリの例を示します。
- コーディング
- バージョン管理システムへのコミットとプッシュ（GitHubなど分散型バージョン管理システムの場合）
- テスト環境での自動化されたビルド（コンパイル、単体テスト、パッケージング）
Jenkinsなどの継続的インテグレーションサーバーは、コミットされたソースコードが、分散型バージョン管理システムにプッシュされたタイミングで、自動的にソースコードを取得してビルドします。 - モジュールの結合
- テスト環境での自動化された結合テスト
- テスト環境での自動化されたシステムテスト
- ステージング環境へのデプロイ
- ステージング環境での自動化された受入テスト
- ステージング環境での手動受入テスト
その際、必要に応じて、負荷テストやセキュリティテストも行います。 - 本番環境へのデプロイ
このうち、2から5までを継続的インテグレーション（Continuous Integration、CI）といいます。
上記を構成する概念を説明します。
- 単体テスト（Unit Test）
個々のコンポーネントやモジュールを対象に行われるテストです。
単体テストは、開発者が行い、コードが期待通りの機能を果たしているかどうかを確認します。 - 結合テスト（Integration Test）
個々のモジュールが組み合わさった際の動作をテストします。
これにより、モジュール間の相互作用やインターフェースの問題を特定します。 - システムテスト（System Test）
完成したシステム全体の機能や性能をテストします。
システムテストは、要件仕様に基づいて行われ、ユーザーが求める機能や品質を確認します。 - 受入テスト（Acceptance Test）
システムがユーザーの要求を満たしているかどうかを確認するテストです。
受入テストは、ユーザーや顧客が行い、システムが実際の使用環境で期待通りに機能するかを確認します。 - 負荷テスト（Load Test）
システムが所定の負荷やストレスに耐えられるかどうかを確認するためのテストです。
負荷テストは、システムに大量のデータや同時ユーザーを投入して行われます。 - セキュリティテスト（Security Test）
システムのセキュリティ強化を目的として、悪意のある攻撃や脆弱性を検出するテストです。
DevOpsの原則
DevOpsとは、開発 (Development) と運用 (Operations) を組み合わせることで、ソフトウェアを迅速に高い頻度で開発することを可能にする手法のことです。
「The DevOps ハンドブック 理論・原則・実践のすべて」という書籍には、DevOpsを支える次の３つの実践原則について言及しています。
- フローの原則
開発→運用→顧客の左から右へのワークフローを高速にすること。
書籍では、これを実現するため必要な方法として次のことを上げています。- 作業を可視化すること
- WIP（仕掛り）を制限すること
- バッチサイズを縮小すること
- プロセスを自動化して受け渡しの数を削減すること
- 絶えず制約条件（ボトルネック）を見つけ出すこと
- バリューストリームからムダを取り除くこと
これを見ると、作業のムリ、ムダ、ムラをなくすといいうリーン生産方式、および、アジャイル開発の考え方が反映されていることがわかります。
バリューストリームとは、ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要なプロセスのことです。
バリューチェーンで言えば、主要活動の流れということになります。
また、上記プロセスの自動化には、テストからデプロイまでを自動化する継続的デリバリの考え方が反映されていますし、マイクロサービスアーキテクチャを適用することで、バッチサイズを縮小することができます。 - フィードバックの原則
バリューストリームのあらゆるステージで、すばやくてコンスタントな右から左へのフィードバックフローを実現すること。
書籍では、これを実現するため必要な方法として次のことを上げています。- 発生と同時に問題を知ること
- 新しい知識を作り上げるために組織が一丸となって問題解決に当たること
- 上流での（早めの）品質確保を追求すること
- 下流の（次の）ワークセンターのために最適な出力をすること
これを見ると、フィードバックによって問題の早期発見と解決を図ることで、問題を先延ばしすることなく、安全で回復力（レジリエンス）のある作業システムを構築することができることがわかります。
- 継続的な学習と実験の原則
ダイナミックで統制がとれた科学的なアプローチに基づく実験とリスクテイクを支持し、成功と失敗の両方から組織として学習し教訓を得ていく生産的な高信頼マネジメントの企業文化を生み出すこと。
書籍では、これを実現するため必要な方法として次のことを上げています。- 日常業務の改善を制度化すること
- ローカルな発見をグローバルな改善に転化すること
- 日常業務に回復力を鍛えるパターンを注入すること
- リーダーが学習する文化を奨励すること
これを見ると、継続的な学習と実験によってプロセスを改善する文化をつくりだすことが重要だということがわかります。
継続的な改善は、スクラムのスプリント単位のデータドリブン経営として実行します。
[…] ;ースピードを上げることができる DevOpsは、開発（Development）と運用（Operations）をŁ […]