万人のためのオートメーション: デプロイメントの自動化パターン、第 2 回

ワン・クリックでデプロイするためのパターン、その 2

Java™ デプロイメントは大抵の場合、面倒でエラーを起こしやすい手作業です。そして、それが原因でユーザーがソフトウェアを利用できるようになるまで時間がかかることは珍しくありません。2 回からなる連載記事の第 2 回目では、オートメーションのエキスパート Paul Duvall が、信頼性が高く、一貫性のある繰り返し可能なデプロイメント・プロセスを作成するための重要なパターンをさらに追加で紹介します。このデプロイメント・プロセスは、ワン・クリックで Java アプリケーションをデプロイすることができます。

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall は、Stelligent 社の最高技術責任者です。同社はコンサルタント会社として、開発チームが production-ready software を提供できるように支援しています。彼は Addison-Wesley Signature Series から出版されている『Continuous Integration: Improving Software Quality and Reducing Risk』(Addison-Wesley Professional、2007年、2008年度 Jolt Award を受賞) の共著者で、『UML 2 Toolkit』(Wiley、2003年) および『No Fluff Just Stuff Anthology』(Pragmatic Programmers、2007年) の著作にも貢献しました。



2009年 2月 10日

この連載について

私たちは開発者として、ユーザーのプロセスを自動化するために作業しますが、自分自身の開発プロセスを自動化する機会は見落としがちです。そこで、連載記事「万人のためのオートメーション」では、実用的なソフトウェア開発プロセスの自動化を検討し、自動化を上手に適用するタイミングと方法を教えます。

デプロイメントもまた、ソフトウェアの作成において自動化するのにふさわしい 1 つの側面です。自動化されたデプロイメントには、信頼性が高く、繰り返し可能なプロセスによるメリットがもたらされます。このメリットとはつまり、正確さ、スピード、管理のしやすさが改善されることです。この 2 回からなる連載記事の第 1 回目では、8 つのデプロイメント自動化パターンについて説明しました。今回の記事では同じく有益なデプロイメント手法として、さらに 7 つの自動化パターンを紹介します。

  • バイナリー整合性。すべてのターゲット環境で同じ成果物が使用されるようにします。
  • 使い捨てコンテナー。ターゲット環境を既知の状態にして、デプロイメントのエラーを減らします。
  • リモート・デプロイメント。デプロイメントが中央のマシンまたはクラスターから複数のマシンに対して確実に行われるようにします。
  • データベース・アップグレード。一元管理されたスクリプト化プロセスによって、データベースにインクリメンタルな変更を加えます。
  • デプロイメント・テスト。デプロイメント前後のチェックで、最新のデプロイメントによるアプリケーションが想定通りに機能していることを確認します。
  • 環境ロールバック。デプロイメントに失敗した場合、アプリケーションとデータベースの変更をロールバックします。
  • 保護ファイル。ビルド・システムで使用する特定のファイルへのアクセスを制御します。

図 1 に、この記事で取り上げるデプロイメント・パターンの相関関係を示します (背景色が白のパターンは第 1 回で説明したパターンです)。

図 1. デプロイメント自動化パターン
デプロイメント自動化パターン

この追加した 7 つのデプロイメント自動化パターンは、ワン・クリックによるデプロイメントを支援するために前回の 8 つの自動化パターンをベースにしています。

一度のコンパイルで多数の環境にデプロイする

名前: バイナリー整合性

パターン: タグ付けされたデプロイメントのそれぞれについて、各ターゲット環境で同じアーカイブ (WAR または EAR) を使用します。

アンチパターン: 同じタグに対し、ターゲット環境ごとに個別にコンパイルします。

このトピックについては同僚と何度も議論を重ねた末、すべてのターゲット環境でコンパイルしてパッケージ化するよりも、一度のコンパイルで生成された成果物を複数のターゲット環境にデプロイしたほうがよいという確固たる結論に至りました。例えば、Java Web デプロイメントによって生成されるデプロイメント成果物は Web アーカイブ (WAR) ファイルかエンタープライズ・アーカイブ (EAR) ファイルです。このアーカイブは (開発環境 (DEV 環境) でそうするように) バージョン管理リポジトリーにチェックインして、一度タグを付けるべきです。

一度のコンパイルで多数の環境にデプロイするという考え方に従って、ビルド・マシンで生成された 1 つの brewery.war をターゲット環境のそれぞれにデプロイするというパターンを図 2 に示します。

図 2. 複数の異なるターゲット環境にデプロイされた 1 つの Web アーカイブ
複数の異なるターゲット環境にデプロイされた 1 つの Web アーカイブ

Ant が提供する checksum タスク (MD5 (Message-Digest Algorithm 5) のハッシュ・アルゴリズムを使用) が、ビルド・マシン上でコンパイルされてパッケージ化されたファイルと、それぞれのターゲット環境にデプロイされたファイルが同じであることを確実にします。

成果物は同じでも、デプロイメント構成はターゲット環境によって異なると異論を唱える人もいることでしょう。つまり、シングル・コマンドやスクリプト化デプロイメントの手法を使うと、同じアーカイブ・ファイルを使っているかどうかによらず、自動化プロセスによって、アプリケーションの出力が変わってしまう可能性が多々あるということです。確かにそうですが、ステージング環境 (STAGE 環境) でのソフトウェアのコンパイルとパッケージ化に使用した JDK のバージョンが QA 環境で実行されていた JDK とは異なっていたために、問題のトラブルシューティングに何時間も無用な時間をかけるはめになることも考えられます。さらに、DEV 環境で使用された中央の依存関係管理リポジトリー (Ivy や Maven など) の JAR がステージング環境の JAR と異なっていると、障害が発生する可能性もあります。このようなリスクを考えると、バイナリー整合性を確実にするために、コンパイルとパッケージ化を一度だけ行って多数の環境にデプロイできるようにするべきだと確信しています。


使い捨てコンテナーを使ってデプロイメントのコストを抑える

名前: 使い捨てコンテナー

パターン: インストールと構成を分離することによって、Web コンテナーとデータベース・コンテナーのインストールおよび構成を自動化します。

アンチパターン: コンテナーをターゲット環境ごとに手動でインストールして構成します。

連載「万人のためのオートメーション」の以前の記事、「継続的インテグレーションのアンチパターン、第 2 回」では、「残骸が残ったまま」の環境を片づけると、ビルドの誤検出や検出漏れを防ぐ上で役立つ理由を説明しました。このような問題は永続コンテナーに依存することによって発生しますが、使い捨てコンテナーを使用すれば、その多くが解消されます。使い捨てコンテナーのパターンは、2 つの原則に基づいています。1 つはコンテナーのすべてのコンポーネントを完全に削除すること、そしてもう 1 つはコンテナーのインストールをコンテナーの構成から切り離すことです。これは、一部の人 (特にシステム・エンジニアなど) にとっては極端な概念のように思えるかもしれません。というのも、通常、別のチームがコンテナーを管理しており、開発者や他の人たちからはコンテナーをいじることができないようにわかりにくくなっている、という前提が、この概念では存在しなくなるからです。その一方、デプロイメントの際に発生しがちな問題とそのコストを考えると、使い捨てコンテナーはすべてのチーム・メンバーにとって最大限のメリットをもたらす可能性もあります。

ワン・クリックによるデプロイメント

「もちろんデプロイメントを自動化しました」と言ってくるチームによく遭遇します。そこで、「コマンド 1 つ (ant など) で実動のソフトウェア・アプリケーションを生成することができますか」といった単純な質問をしてみると、大抵は「はい、Web コンテナーをインストールして構成すれば可能です」とか「はい、データベースをセットアップすれば可能です」といった答えが返ってきます。私が考える真の意味での自動デプロイメントの定義は、まっさらな状態のマシンに Java プラットフォームと Ant をインストールし (このステップを省く方法もいくつかあります)、1 つのコマンドを入力するだけで実動のソフトウェア・アプリケーションを完成できるというものです。これができないとしたら「ワン・クリック」とは言えず、デプロイメント・プロセスに人件費というボトルネックが発生します。

図 3 に示す使い捨てコンテナーのパターンは、すべての情報は誰かの頭の中にではなく、(第 1 回で説明したリポジトリー・パターンを使用して) システム内で保持すべきだという考えに基づいています。

図 3. デプロイメント時のコンテナーの削除とインストール
デプロイメント時のコンテナーの削除とインストール

リスト 1 の Ant スクリプトはインターネットから Tomcat ZIP をダウンロードし、コンテナーに残っている以前のデプロイメントの残骸をすべて削除した上で、Tomcat の解凍、インストール、起動を行います。

リスト 1. コンテナーの削除、再インストール、起動、構成を行う Ant スクリプト化デプロイメント
<!-- Check to see if Tomcat is running prior to this -->
...
<exec executable="sh" osfamily="unix" dir="${tomcat.home}/bin" spawn="true">
  <env key="NOPAUSE" value="true" />
  <arg line="shutdown.sh" />
</exec>
<delete dir="${tomcat.home}" />
<get src="${tomcat.binary.uri}/${tomcat.binary.file}" 
  dest="${download.dir}/${tomcat.binary.file}" usetimestamp="true"/>
<unzip dest="${target.dir}" src="${download.dir}/${tomcat.binary.file}" />
<exec osfamily="unix" executable="chmod" spawn="true">
  <arg value="+x" />
  <arg file="${tomcat.home}/bin/startup.sh" />
  <arg file="${tomcat.home}/bin/shutdown.sh" />
</exec>
<xmltask source="${appserver.server-xml.file}"
  dest="${appserver.server-xml.file}">
  <attr path="/Server/Service[@name='${s.name}']/Connector[${port='${c.port}']" 
    attr="proxyPort" 
	value="${appserver.external.port}"/>
    <attr path="/Server/Service[${name='${s.name}']/Connector[${port='${c.port}']" 
	attr="proxyName"
	value="${appserver.external.host}"/>
</xmltask>
<!-- Perform other container configuration -->
...
<echo message="Starting tomcat instance at ${tomcat.home} with startup.sh" />
<exec executable="sh" osfamily="unix" dir="${tomcat.home}/bin" spawn="true">
  <env key="NOPAUSE" value="true" />
  <arg line="startup.sh" />
</exec>

環境を既知の状態にし、きちんと管理された方法でコンテナーをデプロイすることによって、デプロイメントによる大半の問題の原因となっている一般的なデプロイメント・エラーの多くがなくなります。


コマンドを複数の外部環境で実行する

名前: リモート・デプロイメント

パターン: 中央マシンまたはクラスターを使用して、ソフトウェアを複数のターゲット環境にデプロイします。

アンチパターン: それぞれのターゲット環境内でローカルに、手動でデプロイメントを行います。

データベースと Web コンテナーがいったんインストールされてしまえば、後はわけなく開発者のワークステーションでデプロイメントを実行できるはずですが、開発環境と本番環境には大きな違いがあります。組織に複数のプロジェクトと各種のターゲット環境 (テスト環境やステージング環境など) がある場合、すべてのデプロイメントを単一の環境、つまり 1 つのマシンまたはクラスターから一元管理する必要が生じることは珍しくありません。さらに、大抵はチームがビルド・サーバーを使用して各ターゲット環境間のデプロイメントを管理することになります。連載第 1 回で説明した、公開鍵と秘密鍵を使用したヘッドレス実行のパターンを使用すれば、各マシンに手動でログインする必要はなくなります。図 4 に示すリモート・デプロイメントでは、ヘッドレス実行、シングル・コマンド、そしてスクリプト化デプロイメントのパターンに依存して簡単にリモート・マシンにデプロイできるようにしています。

図 4. 複数の環境を対象としたビルド管理サーバー
複数の環境を対象としたビルド管理サーバー

中央ビルド・サーバーからリモートでソフトウェアをデプロイするには、コマンドをリモートからセキュアにコピーして実行するためのメカニズムを使用しなければなりません。ここでは、セキュア・コピー (SCP) とセキュア・シェル (SSH) を用いた 2 つのメカニズムについて説明します。スクリプト化デプロイメントにより (リスト 2 を参照)、中央ビルド・マシンで生成された Web アーカイブが、ターゲット環境にリモート・コピーされます。

リスト 2. マシン間での WAR ファイルのセキュアなコピー
<target name="copy-tomcat-dist">
  <scp file="${basedir}/target/brewery.war" 
  trust="true" 
  keyfile="${basedir}/config/id_dsa"
  username="bobama"
  passphrase=""
  todir="pduvall:G0theD!stance@myhostname:/usr/local/jakarta-tomcat-5.5.20/webapps" />
</target>

WAR ファイルがリモート・ターゲット環境にセキュアにコピーされた後は、Java Secure Channel で SSHExec タスクなどを使って、中央ビルド・マシンからリモートで任意の SSH コマンドを実行することができます。あるいは、ssh でリモート環境に接続し、ローカル側でコマンドを実行するという方法もあります。この方法を使えばリモート・トラフィックの行き来が少なくなるため、デプロイメントに要する時間を短縮することができます。


データベースとデータを既知の状態にする

名前: データベース・アップグレード

パターン: スクリプトとデータベースを使用して、各ターゲット環境でインクリメンタルな変更を適用します。

アンチパターン: ターゲット環境のそれぞれで、データベースとデータに手動で変更を適用します。

図 5 は、スクリプト化デプロイメントの一環として、データベースの更新を自動化するスクリプトを使用する例です。

図 5. インクリメンタルなデータベース更新の自動適用
インクリメンタルなデータベース更新の自動適用

連載「万人のためのオートメーション」では以前、「Hands-free database migration」の記事のなかで、インクリメンタルなデータベース変更を自動的に適用することの必要性について説明しました。スクリプト化デプロイメントの他のスクリプト同様、データベースのアップグレード・スクリプトもリポジトリーにチェックインされます。

LiquiBase (「参考文献」を参照) は、スクリプト化デプロイメントの一環としてインクリメンタルな変更をデータベースに適用し、同じ変更が各ターゲット環境に適用されるようにするためのツールです。リスト 3 では、LiquiBase changelog の一部として SQL スクリプトが呼び出されます。続いて XML で定義されている changelog は、(Ant などのビルド・スクリプティング・ツールに実装された) スクリプト化デプロイメントによって呼び出されます。

リスト 3. LiquiBase 変更セットからのカスタム SQL ファイルの実行
<changeSet id="1" author="jbiden">
  <sqlFile path="insert-distributor-data.sql"/>
</changeSet>

自動データベース・アップグレードについて理解し、これを適用するには、他にも学ぶべきことがたくさんあります。しかしその考え方は、スクリプト化デプロイメントの一環としてアップグレードを実行し、データベースに対するあらゆる変更を、手順書や誰かの頭の中ではなく、システム内で維持するというものです。


デプロイメントのスモーク・テストを実行する

名前: デプロイメント・テスト

パターン: 自己テスト機能のスクリプトをスクリプト化デプロイメントに統合します。

アンチパターン: デプロイメント固有の側面には重点を置いていない手動による機能テストによってデプロイメントを検証します。

図 6 に、デプロイメントの前後でデプロイメント・テストを実行する例を図解します。

図 6. アプリケーションに対するデプロイメントの機能テストの実行
アプリケーションに対するデプロイメントの機能テストの実行

リスト 4 では、正しいツール・バージョンを使用していることを検証する目的で、Ant を使用してデプロイメント前のテストを実行しています。スクリプト化デプロイメントでは多数の内部デプロイメント・テストと併せ、スクリプトによって、使用されている既存のポートのチェック (Web コンテナーのデプロイメント失敗の原因につながることがあります)、データベース接続の検証、そしてコンテナーが起動済みであるかどうかのチェックを行うことができます。

リスト 4. デプロイメントの有効性を確認するデプロイメント前のチェックの実行
<condition property="ant.version.success">
  <antversion atleast="${ant.check.version}" />
</condition>
<antunit:assertPropertyEquals name="ant.version.success" value="true" />
<echo message="Ant version is correct." />
<echo message="Validating Java version..."/>
<condition property="java.major.version.correct">
  <equals arg1="${ant.java.version}" arg2="${java.check.version.major}" />
</condition>
<antunit:assertTrue message="Your Java SDK version must be 1.5+. \
  You must install correct version.">
  <isset property="java.major.version.correct"/>
</antunit:assertTrue>

さらに範囲を広げたデプロイメント・テストでは、アプリケーションの機能が正常であることを確認することができます。また、Selenium (Web アプリケーションの場合) や Abbot (クライアント・アプリケーションの場合) などのツールを使用して作成したデプロイメント固有の自動機能テストで、デプロイメントの変更が適切に適用されていることも確認することができます。これらのテストはいわばスモーク・テストのようなもので、テストする必要があるのはデプロイメントによって影響される機能だけです。一例として、表 1 に Web アプリケーションの場合に考えられる Selenium やその他のツールの使い方を説明します。

表 1. デプロイメント・テスト
デプロイメント・テスト説明
データベースデータベースに自動的にデータを挿入する機能テストを作成します。このテストによって、データベースにデータが入力されることを確認します。
SMTP (Simple Mail Transfer Protocol)アプリケーションから自動的に E メール・メッセージを送信する機能テストを作成します。
Web サービスSoapAPI などのツールを使用して Web サービスをサブミットし、出力を確認します。
Web コンテナーすべてのコンテナー・サービスが正常に動作していることを確認します。
LDAP (Lightweight Directory Access Protocol)アプリケーションを使用して LDAP による認証を行います。
ロギングアプリケーションのロギング・メカニズムを使用してログを書き込むテストを作成します。

自動テストの目的は、ユーザー機能をテストするためだけではありません。デプロイメント・テストに焦点を置いたテスト・スイートを作成することによって、デプロイメントの有効性を確認し、ダウンストリームのエラーと開発コストを削減することもできます。


デプロイメントのすべての変更をロールバックする

名前: 環境ロールバック

パターン: デプロイメントが失敗した後に、シングル・コマンドによって変更を自動的にロールバックできるようにします。

アンチパターン: アプリケーションおよびデータベースの変更を手動でロールバックします。

図 7 に、自動プロセスで Web デプロイメントをロールバックするだけでなく、データベース・アップグレードによるデータベースの変更をロールバックする仕組みを図解します。

図 7. デプロイメント変更のロールバック
デプロイメント変更のロールバック

デプロイメントを自動化しているかどうかにかかわらず、デプロイメントが上手くいかない場合に変更をロールバックする方法を用意しておくと役に立ちます。場合によっては、誤った変更が原因でシステム停止が発生し、組織にとって何百万ドルもの損害になる恐れがあるからです。環境ロールバックを実行するにはターゲット環境をデプロイメント前の状態に戻さなければなりませんが、それには当然、すべての変更に対するロールバック・スクリプトが必要になります。Web デプロイメントの場合、大抵はロールバックする必要のある変更が多くなります。環境ロールバックの一例としては、デプロイメントの前にアーカイブ (WAR ファイルなど) をコピーしておいて、変更ごとにデータベースのロールバック・スクリプトを指定するという方法があります。また、Web コンテナーに適用された構成変更を適用しなおす必要もあります。

リスト 6 は、LiquiBase を使用してロールフォワード・ステートメントごとにロールバック・ステートメントを提供する例です。このコードでは、対応する dropTable ロールバック・ステートメントを指定すると同時に、brewery という名前の新しいテーブルを追加しています。

リスト 6. インクリメンタルなデータ・アップグレードを適用する際に同時に提供されるロールバック・プロセス
<changeSet id="rollback-database-changes" author="bobama">
  <createTable tableName="brewery">
    <column name="id" type="int"/>
  </createTable>
  <rollback>
    <dropTable tableName="brewery"/>
  </rollback>
</changeSet>

上記の例は、わかりやすいように単純にしてあるのであって、ロールバックを平凡なものにしているわけではありません。前回デプロイしたときの状態に戻すのは、実行するのも自動化するのも、大抵は複雑で時間がかかるプロセスです。ロールバック・スクリプトの作成に費やした時間は、デプロイメント失敗によるコストと比例するはずです。


情報を盗み見されないように保護する

名前: 保護ファイル

パターン: リポジトリーを使用して、許可されたチーム・メンバーだけがファイルを共有するようにします。

アンチパターン: ファイルをチーム・メンバーのマシン上で管理したり、許可されたチーム・メンバーがアクセスできる共有ドライブに保管したりします。

図 8 に示す保護されたバージョン管理リポジトリーは、許可された関係者やシステムだけがアクセスできるファイルを収容するために使用します。

図 8. 機密ファイル用の保護されたバージョン管理リポジトリーの使用
機密ファイル用の保護されたバージョン管理リポジトリーの使用

場合によっては、限られたチーム・メンバーだけが環境固有のデータにアクセスできるようにしなければならないことがあります。ただし、環境固有の情報をデプロイメント・スクリプトから分離すると、スクリプトが実行できなくなる可能性があります。ヘッドレス実行のパターンについて説明した際に、人間がコマンドを入力することなく、セキュアにファイルをコピーしてリモート・コマンドを実行するには、Java Secure Channel で SSH 鍵を使用すると説明しましたが、外部化構成に使用するプロパティーには、すべてのチーム・メンバーには見せるべきではないデータが含まれていることが考えられます。そこで、ヘッドレス実行を確実にすると同時に、.properties ファイルのデータが盗み見されないようにするために私が使用した手段は、これらのファイルを保護されたリポジトリーにチェックインするという方法です。

リスト 7 で構成しているApache がホストする Subversion リポジトリーは、特定のディレクトリーへのアクセスをすべて拒否した後、特定のユーザーのみに明示的にアクセスを許可しています。

リスト 7. Apache と Subversion を使用した Subversion リポジトリーの保護
<DirectoryMatch "^/.*/(\.svn)/">
  Order deny,allow
  Deny from all 
  Allow bobama,jbiden,hclinton
</DirectoryMatch>

Subversion リポジトリーへのアクセスを保護することによって、スクリプト化デプロイメントはパスワードの入力を促されることなく許可されたユーザーの 1 人としてプロパティーにアクセスし、SSH 鍵を使用した方法でヘッドレス実行を実現できます。


ワン・クリックによるデプロイメント

私がこれまで集めてきたデプロイメント自動化パターンは、この連載で 2 回にわたって説明してきた 15 のパターンの他にもありますが、今まで遭遇してきたデプロイメントのさまざまな状況の 80 パーセントは、おそらくこの 15 のパターンで対処することができます。15 のパターンはいずれも、ありとあらゆるターゲット環境で、1 つのコマンドによる文字通りワン・クリックのデプロイメントを実現できるように意図されたものです。読者の皆さんが、苦労せずにデプロイメントできることを願っています。

連載はこれで終わりです

この記事が、連載「万人のためのオートメーション」の最終回です。この壮大な試みでは、これまで 2 年以上にわたり、私の経験を皆さんと共有してきました。私がこの連載で常に目標としてきたことは、いくつものソフトウェア開発プロセスを自動化する方法と、自動化する理由を明らかにすることです。ソフトウェア開発プロセスを自動化することで、エラーを起こしやすい繰り返しの作業で時間を無駄にすることなく、興味深い問題により多くの時間を費やせるようになります。この連載では、適切にリファクタリングするためにコードのレビューを自動化する方法、アプリケーション・データベースをインクリメンタルにアップグレードする方法、継続的インテグレーションのプラクティスとツールを適用する方法、変更のたびに自動的にテストを実行する方法、GUI インストーラーを生成する方法、ワン・クリックでデプロイメントを行う方法、開発者向けのドキュメント生成を自動化する方法、依存関係を管理する方法、バージョン管理リポジトリーを活用する方法、そして各種のビルド・スクリプトとツールを効果的に使用する方法を説明してきました。私がこの連載を執筆するのを楽しんできたのと同じように、読者の皆さんに連載を楽しく読んでいただけたことを願っています。

参考文献

学ぶために

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

  • Ant: Ant をダウンロードして、分かりやすく繰り返し可能な形でソフトウェアのビルドを開始してください。
  • JSch:セキュアな通信を可能にする JSch (Java Secure Channel) をダウンロードしてください。
  • Selenium: デプロイメントに固有の実行テストを実行するには、Selenium をダウンロードしてください。
  • LiquiBase: LiquiBase をダウンロードして、自動データベース・マイグレーションを始めてください。
  • Abbot: Abbot をダウンロードして、デプロイメント中心の機能テストを行ってください。

議論するために

コメント

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=Java technology
ArticleID=376131
ArticleTitle=万人のためのオートメーション: デプロイメントの自動化パターン、第 2 回
publish-date=02102009