DevOps

顧客の要望について行けるため、開発のパイプラインを作らなければならない。すべてのことをバージョン管理下に置いて、全般の環境作成プロセスを自動化し、テストと本番環境を作れるように開発パイプラインを用意し、完全に要望に応じてコードを配置する。これらはやらなければならないことだ。

- Erik to Grasshopper, The Phoenix Project [2]

DevOpsの概要

エンドユーザーが自分たちの環境でソリューションをうまく運用できた時点のみ、本当の実際の開発価値が生まれる。これを実現するために、開発時に、本番配置の複雑な日常作業に対し、意味のある早期の注意を払わなければならない。

エンドユーザーにより素早い価値のフローを確保するため、この文書は開発と配置運用(一般的に「DevOps」)のより固い結合ができるようにいくつかのメカニズムを提示する。これは、部分的に、アジャイルリリース列車(ART)にあるアジャイルチームに、運用チームのメンバーを入れることによって実現する。システム能力及びフィーチャー開発タイムラインの全般を通じて、継続的に配置準備ができているように維持することに関して、我々は具体的な案を提供する。これによって、より頻繁に本番環境に配置する能力を企業に与え、そして、企業は継続的な最短なリードタイムで業界の先頭に立つ。

詳細

価値のストリームには配置運用は不可欠である

エンドユーザーに、使える、信頼できるソリューションを納品することはソフトウェアとシステムエンジニアリングのゴールである。リーンとアジャイルはともにこれをより頻繁に確実にする能力を強調する。開発サイクルタイムを系統的に低減すること、「作り込み品質」アプローチを導入することによって、開発プロセスを「リーン」にし、開発組織はより迅速な開発フローを徐々に確立することを支援する。しかしながら、多くの場合、開発チームは大きなバッチでソリューションを納品し、配置する。新しいソリューションの実際の配置とリリースは手動で、誤りがちで、予測不可という傾向がある。結果として、確約されたリリース日と納品された品質へ影響が出る。対照的に、多くの組織が非常に効果的なリーン生産設備を持っているが、価値のストリームの開発サイドと同期してない。

組織がビジネスに効果的に価値を納品できるように、より「リーン」なアプローチを適用しなければならない。このアプローチはより小さなバッチサイズを取り入れ、システム能力の定義から、ユーザーが実際に恩恵を受ける時点までの配置準備ができていることを含む。それで、我々は継続的な納品により近寄ることができる。これは多くの企業の最終的なゴールである。この文書は主に内部及び外部のITソフトウェア開発のためのDevOpsプラクティスにフォーカスするが、DevOpsは一連のプラクティスだけではなく、ソフトウェア及びシステム開発のより大きなコンテキストで適用できる。もっと重要なことは、DevOpsは人々の考え方を変えることにより、縦割り組織を破壊する。そして、迅速な、有用なフィードバックを得られ、最高な経済効果及び顧客を喜ばせる開発製品をもたらすための作業の流れや協力を改善する。注意:このトピックに関する詳細について、このビデオをご参照(Scott Prugh、DevOps Enterprise Summit 2014)。

配置運用は「列車に乗る」必要

SAFeでは、価値のストリームはソフトウェア作成と納品のすべてのステップをカバーする。アジャイルリリース列車は自己組織化されたアジャイルチームのチームである。リリースの安定なストリームを介し、特定の価値のストリームにおける効果的な価値のフローを可能にするため、アジャイルリリース列車が設計された。1つのARTによって実現できる価値のストリームもあるが、沢山のARTによって実現するものもある。効果的な配置パイプラインとプロセスを確立するため、配置運用チームメンバーは列車に活躍し、プロセスに専属することがきわめて重要である。複数のARTからなる価値のストリームでは、DevOpsは列車の一部であり、価値のストリームレベルにおけるソリューションチームの一部でもある。DevOpsはシステム管理者、DBA、運用エンジニア、ネットワークとストレージエンジニアからなる。しかしながら、DevOpsの原則、価値及びプラクティスは製造専門家や、他の従来ソリューションを配置し、稼働を保証する責任を持つメンバーにも適用できる。このチームはアジャイルリリース列車の共有された、リアルタイム開発と納品のコンテキストで運用作業をしなければならない。ものを構築したり、接続したりする人にとっては、IoT(Internet of Things)は市場を破壊する次の波である。広く分散されたソフトウェア、ハードウェア及びシステム、IT運用の結合、迅速な配置に欠かせない品質プラクティスをどのように対処するか、というような新しい考え方が必要となる。

このチームはアジャイルリリース列車の一部として、ARTのイベントを参加し、他のチーム、システムとソリューションアーキテクト/エンジニアリング、及びビジネス責任者とやり取りを行い、プログラムPI目標と一致するDevOps活動のバックログを作成し、維持する。すなわち、PI計画策定、バックログの手入れ、スクラムオブスクラムズ、システムデモソリューションデモ検査と適応の活動に関して、配置運用チームは一定レベルの参加が求められている。また、配置作業のパイプラインの可視化も重要である。これによって、開発チームと配置運用チームが協調で作業を行うことができ、コードが配置され利用された時点から生まれた価値のフローを確実にする。

配置パイプラインを構築するための6つの推奨プラクティス

効果的な配置パイプラインを確立ため、以下、我々は6つの具体的なプラクティスを推奨する。その前に、結果を達成するためのより広範的、より自動化された環境に対する理解を持たなければならない。

Figure 1. Deployment pipeline environment
図1. 配置パイプライン環境

図1から、サポートしなければならないプロセスが3つあると分かる。

  1. バージョン管理から、コード、スクリプト、テストやメータデータなど、すべて必要な成果物を自動的に取得する。
  2. ステージング環境にて、コードの結合、配置と検証を自動的に行う。可能な限り、自動化される。
  3. 検証されたビルドをステージング環境から本番へ配置し、新しいシステムの検証を行う。

#1 本番相当のステージング環境を構築し、維持する

図1は重要な資産であるステージング環境を示す。ほとんどの配置環境は本番環境と違うという事実から、この環境へのニーズが生まれた。例えば、ファイアウォールは後ろにアプリケーションサーバーが置かれていて、前にロードバランサがある。ほとんどの大規模の本番データベースはクラスター化され、媒体コンテンツは独立のサーバーにある、など。開発環境から本番環境へ移行時に、配置が失敗すると、デバッグや対策は予測できない時間がかかるというマーフィーの法則が的にあたる。それを避けるために、企業は、本番環境と同じあるいは類似なハードウェアを持ち、ソフトウェアシステムをサポートするステージング環境を構築すべきだ。そして、プログラムチームは配置準備のため、ソフトウェアを継続的に検証できる。本当の本番と同等の環境を用意することは経済的実行できないかもしれないが、数百また数千台の必要なサーバーを複製するというような投資がなくでも、同等な機能を達成する方法が多数ある。例えば、20の代わりに、アプリケーションサーバーの2つのインスタンスだけで十分かもしれない。ロードバランサ環境で新しい機能性を検証するため、同じベンダーからのより安いロードバランサも十分かもしれない。

#2 本番によりよくマッチする開発とテスト環境を維持する

開発のために必要となるさまざまな開発環境(特に大規模は日課である分散開発の場合)が本番環境と一致しないという根本原因に対し、これは1つの解決策である。これによって、この根本原因が軽減することも可能である。この根本原因に関する一部の理由はコストである。それは配置の本当の遅延コストに対する理解不足によって生じた実際な経済性によって駆動された。例えば、各開発者がそれぞれロードバランサを持たせるのは非現実である。一方、以下を通じて、ソフトウェアの設定はすべての環境で余裕をもって複製できることを実現できる。
a)コンポーネントやシステム更新への支援、設定、システムメタデータにある変更、他の環境に戻るような、本番環境におけるすべての変更を伝える
b)各回の配置中に、新しい開発によって生じた本番環境に関する設定/環境変更を持続的に忠実に伝える
上記2つのケースの場合、設定変更はバージョンコントロールに捉えなければならない。配置フローを可能にするために必要なすべての新しいアクションはスクリプトに書かなければならないし、可能な限り自動化されなければならない。

#3 スプリント毎にステージング環境に配置し、頻繁に本番環境に配置する

3a: スプリント毎にステージング環境に配置する。インクリメントの状態を客観的に理解するために、確実に配置の準備ができなければならない。これをより確実にするために、1つのシンプルなルールを提案する:最後のシステムとソリューションデモを含む、すべての2週間毎のシステムデモは、ステージング環境から実施する。このように、配置可能性は各ユーザーストーリーの完了の定義の一部となる。そして、各反復毎の結果として、潜在的に配置可能なソフトウェアがある。

3b: 頻繁に本番環境に配置する。信頼できるソフトウェア納品プロセスを確立するために、継続的な配置準備は非常に重要である。一方、リードタイムを短縮することによって得られる本当の恩恵は頻繁に本番環境に実際に配置することによって生まれる。こうすることによって、長期的な本番サポートブランチや、すべてのインスタンスにわたって変更をマージと同期しなければならない必ず発生する余計な労力をなくすことに役に立つ。図1は完全に自動化されたモデルを示したが、本番環境に「自動的にプッシュ」を許可する前に、リリースガバナンスを検討しなければならない。このガバナンスは通常「リリース管理」下で行い、以下のことを検討する

  • ユーザーニーズの全体に満すように(リリースをご参照)、フィーチャーセットの概念上の一貫性
  • 品質、規則、セキュリティなどの要求に関する評価
  • 顧客、チャンネル、本番、外部の市場のタイミングに関する考慮に対する潜在的な影響

#4 すべてをバージョン管理下に置く

確実に本番環境に配置できるように、すべての配置可能な成果物、メタデータ、と他のサポート設定項目はバージョン管理下に維持されなければならない。現実に更新され、修正され可能性のあるすべてのもの、例えば、新しいコード、すべて必要とされるデータ(用語集、スクリプト、ルックアップ、マッピングなど)、すべてのライブラリーと外部アセンブリ、設定ファイルやデータベース、アプリケーションやデータベースサーバーなど、バージョン管理下でなければならない。テストデータも同じアプローチを適用する。チームにとっては、新しいテストシナリオを導入したり、既存のシナリオを修正したりするたびに、テストデータを更新する。そのため、テストデータは十分な管理可能性が必要である。テストデータがバージョン管理下に置かれ、確定的なテスト環境にテストを繰り返して実行することによって、、最新のビルドに関する迅速かつ確実なフィードバックが提供できる。

#5 環境を自動的に構築するための能力作りを始まる

運営環境やアプリケーションとデータの準備、成果物の設定、システム及びサポートシステムにおける必要な作業の始動など、実際のランタイム環境を構築するために必要な手動的、集中な日常作業に間違いが発生しやすい。沢山の配置問題はここから生じる。安定な配置プロセスを確立するため、環境セットアッププロセス自身は完全に自動化されなければならない。仮想化を利用したり、サービスとしてのインフラー(IaaS)を利用したり、設定管理作業の自動化のために特殊なフレームワークを適用したり、これらによって、この自動化が継続的に促進される。

#6 実際の配置プロセスの自動化を始まる

最後に、当然だが、実際の配置プロセス自身も自動化が必要である。この自動化は、対象となる環境(開発、ステージング、本番)におけるコードのビルド、テスト環境の構築、自動化されたテストの実行、検証されたコードや関連システムとユティリティの配置や確認など、フローにある全てのステップを含む。この最終的な、重要な自動化ステップはインクリメンタルなプロセスを介して実現する。チームは自動化の対象範囲を優先するため、組織の完全な確約とサポートが欠かせないが、創造性と実用性も求められている。

配置可能性とソリューションのアーキテクチャー

コード自身はもちろん、設定、インテグレーションスクリプト、自動化されたテスト、配置スクリプト、メタデータ、サポートシステムも全体ソリューションの重要な一部である。このような理解が、継続的な配置準備に対するリーンなシステムアプローチに欠かせない。ユーザーとビジネスのゴールをより速く達成するために、全ソリューションのコンテキストが検討されなければならない。非機能要求について、配置可能性に関する設計は、最少な手動労力で、迅速かつ完璧な納品プロセスというゴール向けに、システムアーキテクト、アジャイルチームと配置運営の協力を介する意図的な設計が求められている。また、より効果的な配置テクニックを適応することを支援するために、組織は一定な企業レベルのアーキテクチャーエピックの取り組み(共通の技術スタック、ツール、でーたの準備と正規化、サードパーティのインターフェイスとデータ変換、ログとレポートツールなど)を取りかからなければならない。この取り組みは配置の準備支援において、アーキテクチャー、インフラーと他の非機能検討を徐々に強化する。価値のあるソフトウェアの納品プロセスを脅かしたり、複雑させたり、というようなことは最終的に改善されなければならない。


さらに知りたい場合

[1] Humble, Jez and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010. (邦訳:継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化、KADOKAWA/アスキー・メディアワークス、2012)

[2] Kim, Gene, et al. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013. (邦訳:The DevOps 逆転だ!、日経BP社、2014)

[3] Prugh, Scott. Continuous Delivery. /continuous-delivery/ by Prugh, on the same topic, from DevOps Enterprise Summit 2014.

Last update 30 November 2015