アジャイル DevOps: ソフトウェア・リリース・プロセスのフラット化

DevOps はソフトウェア・デリバリーの形をどのように変えるのか

ソフトウェア・リリース・プロセスを「フラット化」するとは、何を意味するのでしょうか。そして、それによって組織構造にはどのような影響があるのでしょうか。連載「アジャイル DevOps」の第 1 回では、DevOps のエキスパートである Paul Duvall が、開発部門と運用部門が 1 つのソフトウェア・デリバリー・チームとして連携することで、ソフトウェアの開発およびリリースのプロセスを効率化する仕組みについて説明します。テスト駆動型インフラストラクチャー、一時環境、そして Chaos Monkey といった新たなトピックを取り上げ、これらを使用した手法のすべてが、ソフトウェアをより迅速かつより頻繁にユーザーに提供するという目標に向けてどのような効果をもたらすのかを説明します。

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall は、Stelligent の CTO です。数々の主要なソフトウェア・カンファレンスでメインの講演者を務めている彼は、ソフトウェア・プロジェクトの開発者、プロジェクト・マネージャー、アーキテクト、およびテスターと、実質上すべての役割を担当した経験を持ちます。彼が中心的な著者となった共著書『継続的インテグレーション入門 開発プロセスを自動化する 47 の作法』(Addison-Wesley、2007年) は、2008年度の Jolt Award を受賞しました。また、『Startup@Cloud』、『DevOps in the Cloud LiveLessons』(Pearson Education、2012年6月) の著者でもあります。その他の本にも貢献し、developerWorks では 20 の記事からなる連載「万人のためのオートメーション」を書いています。彼は、継続的デリバリーとクラウドを利用して、高品質のソフトウェアをより短時間に、より頻繁に提供することに熱意を持っています。Stelligent.com で彼のブログを読んでください。



2012年 9月 27日

この連載について

開発部門は、運用部門から多くのことを学べます。同じく運用部門も開発部門から多くのことを学べます。この連載では、運用部門の考え方と開発部門の考え方を相互に適用し、ソフトウェア製品をこれまでよりも迅速かつ頻繁に提供可能な総体的要素として捉える場合の実用性を探ることに話題を絞ります。

ソフトウェアをユーザーに提供するという点に関して言うと、多くの組織でアジャイル開発の成果はまだ一部しか現われていません。その理由はさまざまですが、その核心にある問題は、部門間で密接な連携ができる組織構造になっていないことです。大抵の企業では、開発チームと運用チームが別々の部門となっており、チーム間で共通しているのは CEO だけです。そして、その CEO は部下の幹部を信頼して意思決定を行っているのが通常ですが、開発チームの目標と運用チームの目標は、本来対立します。開発に対する評価基準は、ビジネスで使用できるようになった機能の数に置かれますが、運用に対する評価基準は、システムのアップタイム、つまり安定性に置かれるためです。このような企業にはソフトウェア・システムに対する総体的な見方が欠けているため、いずれのチームにしても、安定した環境で動作する高品質の機能を定期的に提供するという目標を達成するように正しく奨励されていません。

2005年に出版された Thomas Friedman 氏の著書『フラット化する世界 (原題: The World is Flat)』では、グローバル化、ソフトウェア、インターネット、そして一部の発展途上国での国境開放などの要因が合わさって、世界経済へ参入する上でのこれまでの障壁を「フラット化」しつつあると分析しています。ソフトウェア業界では現在、競争上の優位性を求める企業の内部でソフトウェア業界に固有の「フラット化」の傾向が見られます。それは、ソフトウェア・リリースおよび組織構造のフラット化です。このような企業では、自動化、ツール、コラボレーション、そして業界のベスト・プラクティスとパターンといったものが 1 つにまとまることによって実現されるこのフラット化という変革により、ソフトウェア・デリバリーの迅速さ、品質、コストを改善しています。

この連載では、ソフトウェア・システムを総体的に捉える方法、そして安定した機能を定期的に提供するという目標を達成するためには、どのようにしてソフトウェア組織をフラット化しなければならないかを明らかにします。今回の記事では、この連載を通して取り上げる数々のトピックについて紹介します。具体的には、アジャイル、DevOps、業界で新たに出現したパターン、ツール、そしてコラボレーションです。これらのすべてが、上述のソフトウェア・デリバリーについての目標達成に貢献する要素となります。

参加してください

developerWorks の Agile Transformation コミュニティーでは、読者の皆さんおよび皆さんの組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

アジャイル + DevOps

アジャイル・マニフェスト (「参考文献」を参照) の 12 の原則のうち、3 つの原則ではソフトウェア・デリバリーに関する以下のプラクティスを強調しています。

  • 「顧客満足を最優先し、価値のあるソフトウェアを短期間で継続的に提供する」
  • 「実際に動作するソフトウェアを 2、3 週間から 2、3 ヶ月の間隔で、タイムスケールがより短くなることを優先して頻繁に提供する」
  • 「実際に動作するソフトウェアを、進捗度を測る最も重要な尺度とする」

このマニフェストは 10 年以上も前に作成されたものですが、多くの組織が今でもこれらの原則に従おうとしています。その一方で、興味深いことに、アジャイル・マニフェストの原則のさらに上を行っている組織もあります。一部の企業では、ソフトウェアがいつでもリリースできる状態になっていて、チームの間を隔てる壁があることも、それぞれのチームが孤立していることもありません。そのような企業では、開発、QA、データベース、運用などをそれぞれ専門とするエキスパートで構成された 1 つのデリバリー・チームが、価値のあるソフトウェアを継続的にユーザーに提供しています。アジリティーとは、まさにこのことです。

基本的に、DevOps ムーブメントに至る動機となるのは、複数のチームでのソフトウェア・システムのリリースおよび保守に伴うフラストレーションです。典型的なソフトウェア・プロジェクトでは、大まかに言って、開発チームがソフトウェアの開発を担当し、運用チームがソフトウェアの提供を担当します。この 2 つのチームの間にはコラボレーションが必要ですが、それぞれの動機は矛盾します。開発の動機となるのは、新しい機能を実現することですが、運用を動機付けるのはシステムの安定性を確実にすることです。多くの場合、チーム間でのコミュニケーションがとれていないため、それが後になってソフトウェア・デリバリー・プロセスの失敗へとつながります。

DevOps ムーブメントの目標の 1 つは、開発部門と運用部門が今までよりも連携した形で協力できるようにすることです。その結果、開発部門と運用部門の両方の長所を組み合わせてユーザーに価値をもたらすという、新しいタイプの DevOps エンジニアが誕生しています。さらに、開発、構成管理、データベース、テスト、およびインフラストラクチャーに熟練した機能横断型チームの誕生という形でも、その成果が現われています。


パターン

ソフトウェア・パターンとは、特定のコンテキストでの問題に対するソリューションのことです (コンテキストは、パターンを「ベスト・プラクティス」と区別するカギとなります)。アジャイル DevOps に関連付けられたパターンの一例としては、スクリプト化された環境、テスト駆動型インフラストラクチャー、Chaos Monkey、あらゆるもののバージョン管理、デリバリー・パイプライン、DevOps ダッシュボードなどがあります。この記事では、これらのパターンについて紹介します。連載の以降の記事を読み進めるにつれ、パターンの詳細がわかってくるはずです。

スクリプト化された環境

環境のプロビジョニングを完全に自動化することにより、他の環境では発生しなかったエラーが、ある環境で発生するリスクを軽減します。環境をスクリプト化することで、ターゲット環境での特定のバージョンのソフトウェアの完全性 (つまり、何も変更されていないこと) を検証します。環境がバージョン管理されたスクリプトになっていて、自動化されており、本番環境の唯一のパスの一部となっているのでない限り、環境には何も変更を加えないというポリシーに従うことで、デプロイメント・エラーの根本的原因を判別しやすくなります。スクリプト化された環境には、以下の利点があります。

  • 環境が常に既知の状態に置かれます。
  • セルフサービスの環境およびデプロイメントを可能にします。
  • 環境が独特であることが原因でデプロイメントの振る舞いが異なるという可能性が低くなります。
  • 環境が、本番環境の唯一のパス (およびバージョン) の一部となります。
  • チーム・メンバーの頭の中だけに知識や情報があるという可能性が低くなります。
  • デプロイメントの予測可能性および再現性が改善されます。

このスクリプト化された環境というパターンをサポートするのは、この連載で詳しく学ぶことになるインフラストラクチャー自動化ツールです。そのツールの 1 つが Puppet です。リスト 1 のコード・スニペットに、基本的な Puppet プログラム (「マニフェスト」と呼ばれます) の例を示します。

リスト 1. スクリプト化された環境: Puppet マニフェストである httpd のコード・スニペット
class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

通常は、多数のマニフェストが 1 つのインフラストラクチャーをスクリプトという形で記述します。これらのスクリプトは、アプリケーション・コードとまったく同じようにバージョン管理リポジトリーにコミットされます。

テスト駆動型インフラストラクチャー

DevOps の単純な前提は、開発部門と運用部門との間で互いのベスト・プラクティスとパターンを応用することです。コードと併せてテストを作成するというテスト駆動の手法は、ソフトウェア開発にその起源があります。組織の間でインフラストラクチャー自動化ツールが主流になるにつれ、エンジニアはインフラストラクチャーにテスト駆動のプラクティスを適用するようになってきました。つまり、インフラストラクチャーを (リスト 1 に示したように) スクリプトで記述し、これらのスクリプトにテストを付随させるということです。テスト駆動型インフラストラクチャーには多くの利点があります。以下に、そのいくつかを抜粋します。

  • 継続的インテグレーション・システムによって、インフラストラクチャーの変更がソフトウェア・システムの残りの部分に統合されることから、問題が早期のうちに明らかになります。
  • テスト (およびスクリプト化されたインフラストラクチャー) 自体がドキュメントになります。
  • あらゆるものがスクリプトであり、あらゆるものがテストに記述されるため、有害な変更を隔離しやすくなります。

リスト 2 は、Web サーバーが稼働中であることを検証する単純なシナリオです。ここでは、テストをシナリオとして記述する、Cucumber というビヘイビア駆動開発 (受け入れテスト駆動開発とも呼ばれます) ツールを使用しています。

リスト 2. Cucumber でのインフラストラクチャー・テスト
Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

連載の今後の記事では、テスト駆動型インフラストラクチャーの例をさらに取り上げます。

Chaos Monkey

数年前、Netflix の技術チームが Chaos Monkey と名付けた継続的テスト・ツールを開発しました。このツールは、Netflix の本番インフラストラクチャーで意図的かつ無作為に、ただし一定の間隔でインスタンスを強制終了することで、障害が発生してもシステムが稼働し続けることを確認するためのツールです。最近になって、このツールはオープンソースとしてリリースされました (「参考文献」を参照)。

Netflix では、「Everything fails, all the time (年がら年中、あらゆるものが故障する)」(Amazon.com の CTO である Werner Vogels 氏が作り出した標語) という原則に従っています。Netflix が述べているように、「Chaos Monkey の仕事は、無作為にアーキテクチャー内のインスタンスやサービスをキルすることです。障害が起きてもサービスの提供を継続できることを常にテストしていなければ、最も大事なとき、つまり予期せぬ障害発生時に正常に機能する可能性は低くなります」(「参考文献」を参照)。連載の今後の記事では、Chaos Monkey と、正常に機能している DevOps 環境におけるその役割を探ります。

一時環境

一時環境を使用する場合の一般的な原則は、DevOps チーム・メンバーに提供されるセルフサービス環境の有効期間は、数時間から数日間の間でできるだけ短くすることです。基本的には、ひと通りテストを実行するのに十分な時間が目安となります。ソフトウェア開発プロジェクトでとりわけ大きな問題になるのは、限られた数のインスタンスの構成にさまざまなチーム・メンバーが何日も、何週間も、あるいは何ヶ月も費やすことから、他の人たちはそのインスタンスを使用できなくなるという事態です。この問題は多くの場合、環境がスクリプト化されていないために、リソースが不足することが原因で起こります。何らかのリソースが不足しているとしたら、いったん手に入れたリソースを手放さずに保持したいと思うものです。

環境が完全にスクリプト化されていれば、環境で何かが不足することはありません。あらゆるものがテンプレートに定義されて、バージョン管理システムにチェックインされます。スクリプトに基づく環境は、必要に応じて何度でも終了することができます。このパターンには 2 つの利点があります。まず、他の誰もがリソースを使用できるようになることです。そしてもう 1 つは、何週間も何ヶ月もかけて手作業で何かを作り出すのではなく、何もかも自動化しなければならないという概念が強化されることです。この連載では、一時環境について詳しく説明します。

すべての要素をバージョン管理する

すべての要素をバージョン管理するというパターンは、単純で、自明のことのように思えます。すべての要素とはまさに、インフラストラクチャーから、構成、アプリケーション・コード、データベース・スクリプトに至るすべてです。このパターンを理解するのは簡単かもしれませんが、私の経験からすると、ソフトウェア・システムを作成するために必要な成果物のすべてをバージョン管理しているチームは、まずお目にかかれません。

すべての要素をバージョン管理する目的は、真正なものが格納された唯一の情報源 (「正規版」あるいは「マスター・レコード」とも呼ばれます) を確立することです。つまり、ソフトウェアを総体的な 1 つの単位として扱います。すべてのものをバージョン管理していれば、チーム・メンバーは、頻繁にソフトウェア・システムのバージョンがわからなくなったり、さまざまなバージョンをナビゲートしたりすることがなくなります。この連載では、ソフトウェア・デリバリー・システム構成自体のパーツをバージョン管理する新しいプラクティスについても取り上げます。

すべてがバージョン管理されていることを確かめる単純な方法が 1 つあります。それは、チームの新メンバーに与えられた新しいマシンからバージョン管理ソフトのチェックアウト・コマンドを 1 回実行し、そのチェックアウト・コマンドによって実際に動作する完全なソフトウェア・システムを取得できるかどうかを確かめることです。

デリバリー・パイプライン

Jenkins などの継続的インテグレーション・サーバーでは、デリバリー・パイプラインを構成することもできます。デリバリー・パイプラインとは基本的に、さまざまなタイプのジョブを、前のジョブが成功したことを条件に実行するプロセスのことです。このパイプラインには、コミット・ステージやアクセプタンス・ステージを含め、さまざまなステージを構成することができます。各ステージは、前のステージが成功したことを前提にして構築されます。この手法では、ソフトウェア・システムが本番環境にリリースされるまで、連続する各ステージでのリリース候補によるリスクが低減されます。デリバリー・パイプラインの一例 (Jenkins で表現された例) をリスト 1 に示します。

図 1. 継続的インテグレーション・サーバー Jenkins で表現されたデリバリー・パイプライン
継続的インテグレーション・サーバー Jenkins で表現されたデリバリー・パイプライン。ソフトウェアがたどる 3 つのステージがあります。最初のステージでは、ソフトウェアのビルドが継続的インテグレーション・プロセスを完了した後に、SetupVariables ジョブを使用してすべての変数を設定します。次のステージでは、CreateTargetEnvironment ジョブによってターゲット環境を作成します。3 番目の最終ステージでは、DeployManateeApplication ジョブに表現されているように、アプリケーションをターゲット環境にデプロイします。この 3 つのステージは 1 つの作業単位として実行され、ジョブが 1 つでも失敗すると、すべてのジョブが失敗します。

DevOps ダッシュボード

機能横断型デリバリー・チームが機能と安定性の提供に重点を置くようになった後は、全員を同じ 1 つのページにアクセスさせることが、非常に大きな価値をもたらします。DevOps ダッシュボードには、それぞれの変更が、本番環境にデプロイするまでの工程における各ステージでシステム全体にどのように影響するかが示されます。連載の以降の記事で、開発中のソフトウェア・システムに関するリアルタイムの情報を提供するオープンソースのダッシュボードについて詳しく説明します。


コラボレーション

コラボレーションは、DevOps を支える柱の 1 つです。従来の開発チームと運用チームはバラバラに作業する傾向があり、ソフトウェアをリリースする時点になるまで、チーム間でのコミュニケーションは限られてしまいがちです。そこで、共同所有権を確実にすること、機能横断型チームを確立すること、そしてエンジニアのスキル・セットの幅を広げることが、コラボレーションを強化し、ソフトウェアの定期的な提供を妨げている従来の障壁を打ち崩す手段となります。

共同所有権

共同所有権がプラクティスとなったのは、エクストリーム・プログラミング (XP) や、一般に言うところのアジャイル方法論が確立された頃に遡ります。継続的デリバリーのコンテキストでは、ソフトウェア・システムを構成するすべてのタイプのソース・ファイルを、許可されたすべてのチーム・メンバーが変更できるようにすることに重点が置かれます。変更できるものには、アプリケーション・コード、構成、データ、さらにはインフラストラクチャーまでが含まれます。継続的デリバリーのコンテキストではあらゆるものがスクリプト化されるため、あらゆるものを変更できるというわけです。

機能横断型チーム

機能横断型チームを確立するということは、チーム・メンバー全員がデリバリー・プロセスに責任を持つということを意味します。チームの誰もが、ソフトウェア・システムの任意の構成部分を変更することができます。これに対するアンチパターンは、サイロ化されたチームです。具体的には、開発部門、テスト部門、運用部門のそれぞれに独自のスクリプトとプロセスがあり、同じ 1 つのチームに属していないことを意味します。

機能横断型チームは、必要なすべての部門からの代表で構成され、各部門を個別の集中サービス組織として扱うのではなく、デリバリー・チームが主要な組織構成体となります。デリバリー・チームは、ソフトウェアを絶えず提供することに専念して協力し合いますが、そこにはチーム同士が組織をまたがってコミュニケーションする際に付き物の時間面での障害はありません。それぞれのチームを、(少なくとも) ビジネス・アナリスト、顧客担当者、DBA、開発者、プロジェクト・マネージャー、そして QA およびリリース・エンジニアで構成することを検討してください。機能横断型チームにすることで、コミュニケーションを阻害する「これは私の仕事ではない」症候群がなくなる上に、同じ場所にいるチームや、別の場所にいるチームの間で確立される効果的なコミュニケーションの妨げとなる数々の「壁」もなくなります。

多方面のスキルを持つエンジニア

多方面のスキルを持つエンジニアとは、ソフトウェア・デリバリー・プロセスのあらゆる領域に熟練しているチーム・メンバーのことです。開発者は、データベースに変更を加える方法を理解していなければなりません。データベース管理者は、機能テストを作成する方法を理解していなければなりません。プロジェクト・マネージャーは、自動化されたテストにシナリオを追加する方法を理解していなければなりません。通常、チーム・メンバーはその職務にあった役割を果たし続けます (例えば、DBA は全般的にデータベースに専念するなど)。一方で、知識や情報が共有されていれば、地理的に分散された大規模な組織に伴うコミュニケーションの障害が大幅に減ります。さらに、限られた数の重要人物に依存することなく、ソフトウェアをユーザーにリリースできるようになります。


ツール

ツールは、アジャイル Agile DevOps の重要なコンポーネントです。プロジェクトにどのツールを選ぶかは、それぞれのプロジェクトの要件に依存しますが、必要不可欠の仕様が 1 つあります。それは、そのツールをコマンド・ラインから実行できることです。これは、パイプラインをヘッドレス・モード、またはワン・クリックで実行させるために必要な仕様です (レガシー・ツールがコマンドライン・オプションを提供していないとしたら、スクリーン・スクレイピングでヘッドレス・モードの実行を試してみることもできますが、これは最善の方法ではありません。しかも大抵は定期的な保守が必要になってきます)。表 1 に、標準的な DevOps ツールセットに含まれるツールのタイプをいくつか記載します。このリストでは、ツールの名前よりもツールのタイプに注目してください。

表 1. DevOps の作業をサポートするツール
ツール・タイプツール
インフラストラクチャー自動化Bcfg2、CFEngine、Chef、CloudFormation、IBM Tivoli、Puppet
デプロイメント自動化Capistrano、ControlTier、Func、Glu、RunDeck
IaaS (Infrastructure as a Service)Amazon Web Services、CloudStack、IBM SmarterCloud、OpenStack、Rackspace
ビルド自動化Ant、Maven、Rake、Gradle
テスト自動化JUnit、Selenium、Cucumber、easyb
バージョン管理Subversion、Git、IBM Rational ClearCase
継続的インテグレーションJenkins、CruiseControl、IBM Rational BuildForge

表 1 は、ツールの例を説明するためのリストであり、包括的なリストではないことに注意してください (これよりも詳細なツールのリストについては、「参考文献」を参照)。


より円滑なソフトウェア・デリバリーへの道

ソフトウェア・リリースおよび組織のフラット化は、アジャイル DevOps によって実現されます。今回の記事では、アジャイルという状態、DevOps とは何か、そしてどのようにすれば開発部門と運用部門がより連携して協力することで、安定した環境で機能をより頻繁に提供できるようになるか、といった点について意見を述べました。そして、連載の今後の記事で詳しく説明する新しい DevOps パターンのいくつかを紹介し、最後にアジャイル DevOps によるソフトウェア・デリバリーをサポートするツールの一部をリストにしました。

次回の記事では、スクリプト化された環境パターンをサポートするインフラストラクチャー自動化ツールについて説明します。主要なオープンソースのインフラストラクチャー自動化ツールとして、Chef と Puppet を取り上げます。

参考文献

学ぶために

  • Principles behind the Agile Manifesto」(Agile Manifesto、2001年): アジャイル・マニフェストの原則では、機能するソフトウェアを頻繁に提供することを強調しています。
  • DevOps: ウィキペディアで、DevOps ムーブメントの背後にある方法論および動機について説明しています。
  • 5 Lessons We've Learned Using AWS」(John Ciancutti 著、The Netflix Tech Blog、2010年12月): Chaos Monkey は、Netflix のエンジニアたちが自社のクラウド・システムをサポートするために作成した初期のツールの 1 つです。
  • Continuous Delivery Tools List」:Stelligent が、継続的デリバリーを実装するためのツールを包括的にリストしています。
  • モバイル開発のための DevOps」(Michael Galpin 著、developerWorks、2012年7月): アプリケーションのさまざまなバージョンを多様な機器にデプロイするという問題に取り組む上で、DevOps がどのように役立つかを説明しています。
  • さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks の Technical events and webcasts で最新情報を入手してください。
  • 無料の developerWorks Live! briefing に参加して、IBM の製品およびツールについての情報や IT 業界の動向についての情報を迅速に把握してください。
  • Twitter で developerWorks をフォローしてください。
  • developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。

製品や技術を入手するために

  • Chaos Monkey: Chaos Monkey は、Netflix「Simian Army」の最初のソフトウェア・リリースです。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。
  • developerWorks の Agile Transformation コミュニティーでは、組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, Java technology
ArticleID=837572
ArticleTitle=アジャイル DevOps: ソフトウェア・リリース・プロセスのフラット化
publish-date=09272012