DevOps戦略:開発 – DDevOps#3

devops-practices-development
前回の投稿では一般的な戦略を取り上げたが、それに加えてディシプリンドDevOpsをサポートする共通の開発プラクティスがあるので、以下に見ていこう。

  • カナリアテスト カナリアテストは小規模な実験だ。新しい機能を一部のエンドユーザに提供し、その機能が彼らの興味をひくものか否かを判断出来る。見方を変えると、開発チームはこのテストから、機能の(もしあれば)真の潜在的な価値について、洞察を得ることが出来る。
    例えば、あるeコマース企業は、関連する2つの商品を割引価格で購入することができる新しい機能が売上を伸ばすだろうと考えているかもしれない。同時に、これが全体の収益を減少させる可能性を恐れているかもしれない。
    そこで、彼らは、顧客の5%に2週間の間だけこの機能を提供するカナリアテストを実行することにした。売上と収益を追跡し、この新機能へのアクセスを与えられていない顧客と比較するのだ。新機能がカナリアテストを成功裏にパスすれば、その後、より広い範囲のエンドユーザに提供される(何段階のステップを経て最終的にすべてのユーザに展開するというやり方もある)。カナリアテストを、パイロットテストの極端な形態として見做すことが出来る。
  • スプリットテスト  また、A / Bテストとして知られているスプリットテストは、2つ以上のオプションが並列で実行され、それらの有効性が比較される実験である。
    例えば、銀行が、現金自動預け払い機(ATM)を使った2つの口座間での資金転送のために、3つの異なる画面設計アプローチを考えたとしよう。エンドレスの会議やフォーカスグループ、あるいはモデリングセッションを行う代わりに、銀行は3つすべてを実装しサービスとして並行して提供する。私がATMを使用する時はアプローチAの画面が現れ、あなたがログインするときにはアプローチBが現れるといった具合だ。
    ATMのソフトウェアには、重要な利用状況を把握するためのメトリクスを収集する機能が組み込まれているので、銀行はどのアプローチが最も効果的か決定することができる。スプリットテストの終了後、もっとも効果が高かったアプローチによる画面が、ATMのすべてのユーザに提供される。
  • 自動化された回帰テスト アジャイルソフトウェア開発者は、”品質感染症”と呼ばれることがあるが、それは彼らが質の高いコードを書くことにフォーカスし、出来るだけ早くから出来るだけ頻繁にテストをしたいという欲求を持っているからだ。その結果、自動化された回帰テストは、アジャイルチームにとって共通のプラクティスとなっている。時にはテスト駆動開発(TDD)とビヘイビア駆動開発(BDD)といったテストファーストのアプローチに拡張されていることもある。リグレッション·テスト·スイート(S)には、機能テスト、パフォーマンステスト、システム統合テスト(SIT)、および受け入れテストと、その他多くのカテゴリーのテストを含む。
    アジャイルチームは普通日に何度も自動化テストスイートを実行し、問題をすぐに解決するので、実践していないチームではなしえないような高いレベルの品質を達成するし、開発者はそれを楽しんでいる。テストによっては、特にロード/ストレステストやパフォーマンステストのように、実行に長い時間がかかるものもあるので、異なるケーデンスで実行するテストの組み合わせをいくつか用意することになるだろう(例えば、ある種のテストはコードがチェックインする度に実行されるが、ある種のテストは1日のうちの決まった時間に実行される。また、あるテストは夕方に一度実行され、あるテストは週末に実行される、といったように)。
    品質に対してこれまで以上にフォーカスするというのは、運用スタッフにとっては良いニュースだ。なぜなら運用スタッフとは、ソリューションは本番サービス稼働前に十分な品質が確保されていなければならないと主張するものだからだ。
  • 継続的インテグレーション(CI) 継続的インテグレーション(CI)は、ファイルが構成管理(CM)システムにチェックインされるたびに自動的にプロジェクトをビルドし検証するという原則だ。次の図に見られるように、検証は、自動回帰テスト、さらには、静的または動的なコードおよびスキーマ·分析などの、複数のアプローチで行われる。CIは、コードの不具合に関して迅速なフィードバックを提供することで、開発者が少しずつ繰り返し行われる定常の手順で、安全に高品質のソリューションを開発することを可能にする。devops-practice-cycle
  • 継続的デプロイ(CD) 継続的デプロイは、継続的インテグレーションのプラクティスを拡張したものだ。継続的デプロイでは、あるサンドボックスで統合に成功したら、その変更されたコードは次のステージのサンドボックスに自動的に引き渡される(これを、”昇格する”と呼ぶ)。ソースファイルの変更を受けて、そのサンドボックスで実行されているCI機構があなたのソリューションに統合する。
    下図を見るとわかるように、この自動的な昇格は、いかなる変更も人によって検証されなければならないポイントー一般的には開発から運用へと遷移するタイミングまで続く。今や先進的なチームは、本番環境へのデプロイまで自動的に行っている。継続的デプロイによって、開発チームは、新たな機能が識別され運用に供されるまでの時間を短縮させることができる。それは、ビジネスの応答性能を高めることに繋がる。
    しかし、開発チームが未成熟な継続的デプロイを行っていると、本番環境に潜在的に不具合を紛れ込ませることになり、運用上のリスクを増加させることが起こりえる。エンタープライズレベルで継続的デプロイを成功させるためには、すべてのサンドボックスで実行される、効果的な継続的インテグレーション戦略が必要だ。
    devops-practice-releasepipelineディシプリンドDevOpsの考え方を理解している開発者がソリューションをビルドする際に採用する、運用に親和性の高い共通の機能を以下に挙げてみよう。
  • アクセス制御機能 カナリアテストやスプリットテストのような実験的な戦略をサポートするために、ある特定の機能へのユーザアクセスを制限する機能が必須となる。このアプローチは、設定とデプロイが簡単にできなければならない。よく使われる方法としては、XMLベースの構成ファイルを利用するもので、実行時にメモリに読み込まれ、アクセス権限を制御するためのメタデータが記述される。
  • モニタリング機能 ディシプリンドDevOpsの考え方を理解している開発者は、計測機能ーログの出力とよりリアルタイムに近いアラートーを彼らのソリューションに組み込む。この目的は、運用に入っているシステムを、(ほぼ)リアルタイムで監視出来るようにすることだ。リューションを運用し続ける責任を担っている人々、問題をデバッグし解決する責任を担っている人々、運用インテリジェンスを利用する人々にとって、この機能は重要だ。
    モニタリング機能を組み込むことで、カナリアテストやスプリットテストの際に、テスト中のフィーチャーや戦略の有効性を判断するために必要なデータを収集することができるようになる。
  • フィーチャートグル フィーチャトグルは、適切な場合に機能をオン/オフできるようにする、便利なソフトウェアスイッチのことだ。よくある使い方は、価値ストリームーエピックあるいはユースケースで記述されるーを提供する一連の機能群を、ユーザの受け入れ準備が整った暁に一斉にオンにするといったものだ。フィーチャーがうまく機能していない(エンドユーザにとって有用性が見いだせなかったり、結果として売上減になったり・・・)とわかった時に、特定のフィーチャーをオフする場合にもよく使われる。
    フィーチャートグルのもう一つの利点は、インクリメントベースで、機能を本番運用にデプロイできることだ。
  • セルフテスト ソリューションをより堅牢で、操作しやすいモノにする1つの戦略は、セルフテストが出来るようにすることだ。基本的な考え方は、本番運用中に適切に稼働するということを検証する基本的なテストを、ソリューションの各コンポーネントに含めるというものだ。例えば、アプリケーションサーバーが、オペレーティングシステムやフレームワークのバージョンが適切かを、スタート時に確認するというような基本的なテストを実行する。サーバー稼働中に、データソースやミドルウェアサービスといった関連する他のコンポーネントが利用可能かどうか定期的にチェックすることもある。問題が発見されたときには最低でもログに記録されるべきだし、さらには人による介入が必要なケースにはアラートが挙がったほうがよい。もっと言えば、ソリューション自体が問題からの回復を試みるとなお良い。
  • 自己回復 システムに問題が発生した際に、自動的にそこから回復し以前と同様にサービスを継続させられるのがベストだ。例えば、システムがデータソースが使えなくなったと発見した場合に、データサービスの再起動を試みるといったことだ。再起動が失敗したら、利用できる場所に変更トランザクションを記録し、データサービスが再び復旧するまでそれを処理する。この良い例がATMである。 ATMは、銀行の財務処理システムへの接続を失った際に、限定された機能ではあるが一定の期間独立に使い続けることが出来る。ATMは人々が自身の口座からお金を引き出すことを許す。ただし、過剰に引き出す事がないよう、金額に制限をかけはする。人々は、口座に入金することもできるが、現在の残高を照会したり、最近の取引の記録を見ることは出来ないだろう。自己回復機能は、エンドユーザーに優れた体験を提供し、組織にかかる運営上の負担を軽減する。

ここまでで、一連の開発プラクティスと機能実装について、概要を見てきた。次回の投稿では、運用作業を合理化する戦略について探検していくつもりだ。

オリジナル:DevOps Strategies – Development 

URL : https://disciplinedagiledelivery.wordpress.com/2015/02/08/devops-strategies-development/

(翻訳:藤井 智弘)

 

 

Pocket