万人のためのオートメーション: 継続的インテグレーションのアンチパターン、第 1 回

してはいけないことを学んで継続的インテグレーションを円滑に進める

継続的インテグレーション (CI) はプロジェクトでのリスクを軽減する上で極めて有効ですが、それと同時に、コーディングに関連する日々の取り組みがなおのこと重要になってきます。連載「万人のためのオートメーション」では今回、オートメーションのエキスパートであり、『Continuous Integration: Improving Software Quality and Reducing Risk』の著者でもある Paul Duvall が一連の CI アンチパターンを一つひとつ明らかにし、さらに肝心なその回避方法を伝授します。

Paul Duvall (paul.duvall@stelligent.com), CTO, Stelligent Incorporated

Paul DuvallPaul Duvall はコンサルティング会社、Stelligent Incorporated の CTO および思想的指導者として、開発チームが機動的ソフトウェア作成を最適化できるように支援しています。彼は Addison-Wesley Signature Series から出版されている『Continuous Integration: Improving Software Quality and Reducing Risk』(Addison-Wesley、2007年) の共著者で、『UML 2 Toolkit』(Wiley、2003年) および『 No Fluff Just Stuff Anthology』(Pragmatic Programmers、2007年) の著作にも貢献しました。



2007年 12月 04日

これまでの経験を通じていつも私が思うことは、特定の状況に何が役に立つかを知るよりも、何が役に立たないかを知るほうが得るところが大きいということです。例えば、この仕事を始めて間もない頃、ソフトウェアを短期間でリリースしようとしてユニット・テストを省略したことがあります。ユニット・テストの作業はコストに見合わないと思い込んでいたからです。幸い、テストされていないコードは実動に移しても上手く動作しないことを学び、それからはユニット・テストを作成するようになりました。

このような学習法は、この業界で大方支持されていると思います。実際、特定の状況で上手くいかないプラクティスを捉える独自の言葉として、アンチパターンという造語まで作られているほどです。大まかに言うと、アンチパターンとは、有益なように見えるものの結果的には逆効果になるソリューションのことです。

真実のように見える誤った事実

残念なことに、未経験のチームが CI のプラクティスを導入しようとすると、誤って多くのアンチパターンを取り入れてしまいがちです。これらのアンチパターンは、利益になると思われたものへの大きな不満という結果につながります。さらに残念ことに CI という言葉自体が誤って使われることは多く、そのため、実は CI にはまったく問題がないのに、「CI は大規模なプロジェクトには向かない」、「このプロジェクトは独特なものだから CI は役に立たない」などという発言をよく耳にします。しかし彼らを不満に導いた原因は、あるプラクティスを誤った方法で適用したこと、あるいはそのような慣例を使用しなかったことなのです。

この連載について

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

そこで、この記事では CI のために真実を明らかにし、以下の 6 つのアンチパターンについて詳しく説明しようと思います。

  • 頻繁にチェックインを行わないため、インテグレーションに遅れが生じる
  • ビルドに失敗しているため、チームが他の作業に進めない
  • フィードバックが少ないため、対応することができない
  • やみくもにフィードバックが送られてくることから、人々がメッセージを無視するようになる
  • 遅いマシンを使用していることが原因で、フィードバックに遅れが出る
  • 肥大化したビルドに依存しているため、フィードバックに時間がかかる

CI に長く携わっていくうちに、これらのアンチパターンによる影響を経験することはほぼ間違いありません。アンチパターンが発生すること自体には問題ありませんが、それがあまりにも頻繁だと、CI ならではの多種多様のメリットが限られてしまいます。上記に挙げたアンチパターンの発生と悪影響を抑えたいという方は、ぜひこの記事を読んでください。


チェックインを頻繁に行わないとインテグレーションに遅れが生じます

名前: 低頻度のチェックイン

アンチパターン: ある処理を実行するには多くの変更が必要になるため、リポジトリーからチェックアウトされたソース・ファイルが長い間放置される。

ソリューション: コードのチャンクを小さくして頻繁にコミットする。

CI の導入によってもたらされることは、チームが開発中のコードのステータスについて素早くフィードバックを受けられ、さらには頻繁なソフトウェア・インテグレーションによって従来の時代遅れの「ビッグバン」的なインテグレーション作業にかかっていた時間 (そして、それに伴う苦労) が少なくなることです。その一方、CI を効果のあるものにするには、変更が定期的に行われる (そのため、ビルドを頻繁に行える) ことを前提としています。そのため、コードが長い間 (リポジトリーではなく) デスクトップにチェックアウトされたままだと良くない事態が起こります。なぜなら、その間にシステムのさまざまな部分で他の変更が行われることになるからです。

1 日 1 回のコミットがインテグレーションの悩みの種を遠ざけます

一般的な経験則は、少なくとも 1 日 1 回はコードをチェックインすることです。私が使っている効果的な手法は、休憩したいと思ったら、まずはローカル・ビルドの実行が可能な段階に達しているかどうか確かめてからコードをコミットするというものです。それから休憩に入ります。

基本的に、変更を頻繁にコミットしないということはインテグレーションを遅らせるということであり、その遅れが長引けば長引くほど悪影響 (他の誰かが行った変更によってコードが影響されるなど) を解決するための作業が多くなっていきます。CI を用いたプロジェクトでは、開発者が自分のコードを少なくとも 1 日 1 回コミットすることをお勧めしますが、コードのチェックインに関しては 1 日何度も行うのが最善の策です。

作業を小分けにして簡単になるようにしてください

ここで、一部の開発者たちの怒りの声が聞こえてきます。彼らの不満は当然、山のようなファイルの修正に追われているのに毎日コードをチェックインするのは無理だというものですが、この文句こそが私が言いたいことの要点です。つまり、ソースの変更を毎日コミットするためには小さい規模に分けて考えなければなりません。実際のところ、コーディング作業は複数の簡潔な作業に分けて、変更が小規模で済むようにする必要があります。

例えば、原型の read()write()update()、そして delete() メソッドをコーディングするなどして、一度にすべての機能をビジネス・オブジェクトに実装するのではなく、最初に read() メソッド (そして対応するテストも) をコーディングしたらクラスをチェックインしてコード・ベース全体のインテグレーションを行うようにします。その上で別のメソッドを実装するといったように、このプラクティスをすべての作業が終了するまで繰り返します。このようにすれば CI のメリットが最大限に生かされ、自分のコードが他の人のコードと正常に動作することを常に確信できるようになります。

ここで忘れてならないのは、あなたとあなたのチームが多くの CI プラクティスを正しく実行しているとしても、チームのメンバーが 1 日に最低 1 回ソースの変更をコミットしなければ、チームにもたらされる CI のメリットはごくわずかになってしまうということです。そうなると、たいていの場合 CI は有効でないという認識につながります。これは事実とはかけ離れた認識です。


ビルドの失敗によって開発はスムーズに進まなくなります

名前: ビルドの失敗

アンチパターン: 長い間ビルドに失敗したままになっているため、開発者が正常に動作しているコードをチェックアウトできない。

ソリューション: ビルドに失敗した時点ですぐに開発者に知らせ、ビルドの修正を最優先させる。

信じられないかもしれませんが、ビルドに失敗したままの状態が長引けば長引くほど、ビルドの修正は困難になります。その理由は、時間が経つにつれてファイルも、変更も、そして依存関係も増えてくるため、問題がある箇所の切り分けが難しくなるからです。したがって、ビルドに失敗したことを (E メール、RSS、またはその他の方法で) 知らされた開発者は、問題となっている状況の修正を最優先事項としなければなりません。ビルドに失敗した状態で長い間放置しておけばおくほど (頻繁に変更を行うチームの場合は特に)、措置を講じようとしても、その状況を修正するのが困難になります。

かといって、ビルドの失敗が常に悪いことであるとは限りません。実際、ビルドに失敗するとソフトウェアの問題を早期に発見することができます。ビルドの失敗が問題になるのは、度々ビルドに失敗する場合、あるいは長い間失敗したままの状態になっている場合です。ビルドに失敗した状態ではオフィスを後にすることはできなくなります。

決して失敗することのないビルド

早とちりしないでください。私が言いたいのは、「決してビルドに失敗してはならない」と言う開発者がいますが、これは賢いアドバイスではないということです。ファイルの不足や機能しないテストなど、よくありがちなビルドのエラーの大半は防ぐ必要がありますが、ビルドに失敗しないということは、そのビルドにはそれほどの役割がない可能性があるということでもあります (コンパイルと少数のユニット・テストくらいの役割)。これを私は「継続的イグノランス (Continuous Ignorance)」と呼んでいます。この方が、頻繁にビルドに失敗する場合よりも問題である可能性もあります。

ローカルでビルドをすることによってビルドの失敗は少なくなります

ビルドの失敗を防ぐ上で有効な手法の 1 つとして知られているのは、コードをリポジトリーにコミットする前にローカルでビルドを実行することです。ローカルでのビルドを実行する概略手順は以下のとおりです。

  1. リポジトリーからコードをチェックアウトする。
  2. ローカル側でコードを修正する。
  3. リポジトリーで更新を実行して他の開発者による変更のインテグレーションを行う。
  4. ローカル・ビルドを実行する。
  5. ビルドが成功したら、変更をリポジトリーにコミットする。

図 1 にこのプラクティスを実施する様子を示します。このワーク・フローはリポジトリーとの頻繁な同期を重視しているため、定期的にチェックインできるとともに、ビルドの失敗が限定される点に注意してください。まさに、一石二鳥です。

図 1. ローカルでビルドを実行することによるインテグレーション・ビルドの失敗の削減
ローカルでビルドを実行することによるインテグレーション・ビルドの失敗の削減

ソース・コードをチェックインする前に (当然、これは頻繁に行われます)、ローカルでビルドを実行することによって、結果的にビルドに失敗する典型的なエラーを防ぐことができます。したがって、時間が節約され、頭痛の種が取り除かれるというわけです。


フィードバックがわずかだと対応に遅れが出ます

名前: 最小限のフィードバック

アンチパターン: チームがビルド・ステータスをチームのメンバーに通知しないことに決めたため、周囲がビルドの失敗に気付かない。

ソリューション: さまざまなフィードバックの方法を使用してビルド・ステータス情報を伝える。

チームが CI システムをセットアップするときに、E メールの受信はスパムに匹敵すると考えて「しばらくの間」通知を行わないと決めることはよくあります。しかし、ビルドからのフィードバックが何もなければ、対応することもできません。事実、フィードバックは CI でもっとも重要な側面の一つです。そうは言うものの、フィードバックが効果的であることも不可欠です。

ビルド・ステータス情報をチームのメンバーに伝える方法を拡張するなら、複数のチームが同じ場所にいる場合はことさらのこと、視覚や聴覚に訴える装置を使用するとかなり役立ちます。例えば、Ambient Orb などの機器は、ビルド・ステータスをほぼリアルタイムで視覚的に表す上で効果的です。Ambient Orb の球体はビルドが失敗すると赤くなり、ビルドが成功すると緑になるようにすることができます。さらに球体の異なる色 (良好な場合は青、不良の場合は黄色) によって、コード・ベースのサイクロマティック複雑度が高くなっているか低くなっているかといった情報を伝えることもできます。

想像力を働かせてください

Ambient Orb のセットアップは至って簡単です。一例として、リスト 1 に Quality Lab のオープンソース OrbTask を使って Ambient Orb をセットアップする方法を記載します。

リスト 1. Ambient Orb Ant タスクの使用
<target name="notifyOrb" >
  <taskdef classname="org.qualitylabs.ambientorb.ant.OrbTask"
    name="orb" classpathref="orb.class.path"/>
	<orb query="http://myambient.com:8080/java/my_devices/submitdata.jsp"
	  deviceId="AAA-9A9-AA9"
	  colorPass="green"
	  colorFail="red"
	  commentFail="Code+Duplication+Threshold+Exceeded" />    
  </target>

リスト 1 のタスクは、球体の色を成功ステータスの場合には緑色に、失敗ステータスの場合には赤にするように構成されています。図 2 に示す緑色の球体は、最新のビルドが成功したことを示しています。

図 2. ビルドの成功
ビルドの成功

チームは想像力を働かせてさまざまなフィードバック手法を用いることによって、チーム・メンバーがビルド・ステータス・メッセージを無視し始めることがないようにできます。その上、このような効果的な手法を CI のお決まりのやり方に取り入れるのは面白いだけでなく、必要に応じて対処しなければならない問題が発生したときには即刻注意を促すことができます。

この他の通知手段としては、以下のものも挙げられます。

  • RSS フィード
  • CCTray (CruiseControl 用) などのタスク・バー・モニター
  • X10 機器 (LavaLamps など)
  • Jabber などによるインスタント・メッセージ
  • 家族や友人からメッセージを受け取ることが少ない人には、SMS (テキスト・メッセージ)

1 つ注意する点としては、情報は多すぎることもなく、少なすぎることもないように上手くバランスを取らなければならないということです。フィードバックの手法はチームによってさまざまで、作業環境に応じて定期的に取り替える必要があります。例えば、同じ場所にいる複数のチームには音を鳴らすこと (ビルド失敗時に火事のサイレンを鳴らすなど) は効果的ですが、他のチームにとっては Ambient Orb のほうが好ましいという場合も考えられます (集中して考えているときにサイレンで驚かされることがないため)。


大量のフィードバックは無視されるのがおちです

名前: 大量のフィードバック

アンチパターン: チームのメンバーにビルド・ステータス (成功と失敗、そしてその中間のすべて) に関する E メールが殺到すると、メンバーがメッセージを無視するようになる。

ソリューション: フィードバックの対象を絞り、チーム・メンバーが関連性のない情報を受け取らないようにする。

十分なフィードバックを受け取れないというアンチパターンとは逆に、CI サーバーが何かをするたびに全員にフィードバック (例えば E メール) を送ると決めるチームもよくありますが、過剰なフィードバックを送ることほど「フィードバックを無視しろ」と声高に訴えかけるものはありません。フィードバックが多すぎると、チームはすぐに CI フィードバックをスパムと見なすようになります。そうなると、何か深刻な事態が起こったとしても (ビルドに実際に失敗しているなど)、知られないままになってしまう恐れがあります。

対象を絞ればスパムになることはありません

リスト 2 のサンプル CruiseControl 構成ファイルでは、E メール通知の効果的な使い方が示されています。このサンプルでは、技術リーダーには常にビルドが成功したかどうかの E メールを送信するようになっています。また、プロジェクト・マネージャーにはビルドが失敗した場合にのみ E メールを送信し、最近ソースの変更をリポジトリーにコミットした開発者に対しても通知が行われます。

リスト 2. CruiseControl による E メール通知の送信
<project name="brewery">
...
<publishers>
  <htmlemail 
    css="./webapps/cruisecontrol/css/cruisecontrol.css"
    mailhost="localhost"
    xsldir="./webapps/cruisecontrol/xsl"
    returnaddress="cruisecontrol@localhost"
    buildresultsurl="http://localhost:8080"
    mailport="25"
    defaultsuffix="@localhost" spamwhilebroken="false"> 
    <always address="techlead@localhost"/>
    <failure address="pm@localhost" reportWhenFixed="true"/>
  </htmlemail>
</publishers>	
...

フィードバックが CI システムにとってもっとも欠かせないものの 1 つだということを考えると、フィードバックに関する議論は付き物です。最小限のフィードバックと大量のフィードバックは両極端に位置しますが、その間には最適なフィードバックというものがあります。つまり、ビルドに失敗してしまった場合にはすぐに実用的な情報を伴ったフィードバックを関係者に送り、ビルドが成功した場合には最近変更を行った者や、リーダーとしてこの情報を知る必要がある者など、必要最小限に絞った対象にフィードバックを送るべきだということです。誰彼構わずステータス・メッセージをひっきりなしに送るのは間違いなく、CI プロセスのメリットを瞬く間に制限してしまいます。


遅いマシンによってフィードバックを遅らせないこと

名前: 処理速度の遅いマシン

アンチパターン: リソースが限られたワークステーションをビルド・マシンとして使用しているために、ビルドに時間がかかる。

ソリューション: 最適なディスク速度、プロセッサー、RAM リソースを備えたビルド・マシンでビルド時間を短縮する。

数年前に私が取り組んだ比較的大掛かりなプロジェクトでは、100 万行以上のコードがあり、コンパイルするのに 2 時間以上かかっていました。私たちはインテグレーションを頻繁に行いたかったのですが、構成管理チームがこのコンパイル・プロセスを終えるまで待つ時間は次第に長くなり、苦痛になってきました。当然、コンパイルに 2 時間というのは上手く行った場合のシナリオで、ビルドは度々失敗することもあり、プロセスは完了するまでに数日かかるというのが通常でした (苦痛とはまさにこのことです)。実に時間のかかるこのプロセスが数週間続いた末、ソリューションが明らかになりました。それは、チェックアウトされているファイルとビルドの結果として生成されたファイルすべてに対応できるディスク・スペース、多くの命令を処理できる最速のプロセッサー速度、そしてテストやメモリー消費量の多いその他のプロセスを実行するのに十分な RAM を備えたマシンを購入することです。

処理速度に物足りなさを感じたら

この極めてハイスペックのマシンによって、私たちは 2 時間という極めて長い ビルドの時間を 30 分に短縮することに成功しました。このように、最先端技術のマシンに数ドルを追加でつぎ込んだおかげでチームの時間と経費は大幅に節約され、最終的にはソフトウェアのインテグレーションをするまでの時間を短縮することができました (すなわち、問題を見つけるまでの時間が縮まったということです)。

追加のワークステーションでインテグレーション・ビルドの実行に着手するのは何も間違ったことではありません。しかし、この話の教訓は、処理速度やメモリーに不足を感じた場合、あるいはハードディスクに無理があると思ったら、ビルド・マシンのアップグレードを真剣に検討すべきだということです。ビルドの迅速化による時間の節約は、素早いフィードバックと問題修正につながり、さらには次の開発タスクに早く移行できることにもなります。


肥大化したビルドは迅速なフィードバックの妨げとなります

名前: 肥大化したビルド

アンチパターン: あらゆるタイプの自動検査ツールの実行や負荷テストの実行など、コミット・ビルド・プロセスに何もかも組み入れてしまったためにフィードバックが遅れる。

ソリューション: ビルド・パイプラインによって、さまざまなタイプのビルドを実行できるようにする。

開発チームのなかには、自動ビルドに追加できるプロセスというプロセスをすべて追加することに夢中になって、それぞれのアクションを実行するには時間がかかることを忘れてしまうチームがあります。コンパイルに 2 時間かかった先のプロジェクトが、そのいい例です。このビルド・プロセスの一環としてテストの実行を追加したとしたらどうなっていたでしょう。100 万行以上のコードに対して静的分析ツールを実行した場合、どれくらいの時間がかかるか想像できますか? 8 時間のビルド・プロセスが信じ難いというなら、考えを改めてください。私はそのような信じ難いプロセスに何度も出くわしています。

チームはもっとも多くのビルド情報をメンバーに提供しようとして、次第にビルドを肥大化させてしまいがちです。開発チームに迅速なフィードバックを提供すること、そして CI ビルド・プロセスからの有益な情報を提供することの 2 つを両立させるには、ある方法があります。

ビルド・パイプラインで効率化を図ってください

プロセスの所要時間を改善するためのその他の手段 (高速マシンを手に入れるなど) を講じ、テストの実行時間を最適化したにもかかわらず、ビルド・プロセスにあまりにも時間がかかっていると思った場合は、ビルド・パイプラインとして知られるものを作成する段階に来ているのかもしれません。ビルド・パイプラインの目的は、時間のかかるプロセスを実質的に非同期で実行し、誰かがコードをチェックインしたら、そのフィードバックを受け取るまでに遅れが出ないようにすることです。

例えばビルドを実行するのに 10 分以上かかる場合、ビルド・パイプラインを確立して、誰かがコードをリポジトリーにコミットした後に初期の軽量なビルドが実行されるようにします。このビルドの「コミット」は、(理想として) 短時間のユニット・テストのコンパイルと実行などといった軽量のプロセスで構成されます。この初期ビルドが成功した上で 2 次ビルドを実行し、最初のプロセスよりも時間のかかるテスト、ソフトウェア検査、さらにはアプリケーション・サーバーへのデプロイを実行するというわけです。

その一例としてリスト 3 を見てください。ここで私が構成したのは、リポジトリー内の変更をチェックする CruiseControl です。変更が検出されると、CruiseControl が代行ビルドとして知られるビルドを実行し、プロジェクトのメイン・ビルド・ファイル (Ant を使用している場合は build.xml など) を呼び出します。この構成でユニークな点は、CruiseControl は異なるターゲットを実行し、それによってコンパイルや詳細なユニット・テストなどの軽量のプロセスが実行されることです。

リスト 3. 変更をチェックする CruiseControl の構成
<project name="brewery-commit">
...
  <modificationset quietperiod="120">
    <svn RepositoryLocation="http://brewery-ci.googlecode.com/svn/trunk"/>
  </modificationset
...

リスト 4 では、CruiseControl が brewery-commit プロジェクトに対して変更をチェックするように構成されています (このプロジェクトはリポジトリー内にはないため、実際にはログ・ファイルを調べています)。変更が検出されると、CruiseControl は別の代行ビルドを実行します。このビルドは同じビルド・ファイルを呼び出しますが、ターゲットは異なるため、機能テスト、ソフトウェア検査などの時間のかかるプロセスが実行されることになります。

リスト 4. 長時間のビルドを実行する CruiseControl の構成
<project name="brewery-secondary">
...
  <modificationset quietperiod="120">
    <buildstatus logdir="logs/brewery-commit" />
  </modificationset>
...

肥大化したビルドというアンチパターンは、CI が上手くいかない理由としてもっともよく引き合いに出される言い訳です。しかしご覧のように、ビルド・パイプラインを使えばその言い訳は通用しません。効果的なビルド・パイプラインは「80/20」ルールのメリットを最大限にします。このルールは、ビルド・エラー (ファイルの不足、コンパイルの失敗、テストの失敗など) の 80 パーセントにつながる領域にビルド時間の 20 パーセントを費やすというものです。このプロセスが完了して開発者がフィードバックを受け取った上で、2 次ビルドを実行してください。2 次ビルドにかかる時間は長いかもしれませんが、残り 20 パーセントのビルド・エラーや相対的な優先度の問題が見つかります。


アンチパターンは修正できます

CI のアンチパターンは、チームが継続的インテグレーションのプラクティスを十分に生かす妨げとなりますが、この記事で説明した手法に従えば、このようなアンチパターンが頻繁に発生しないようにすることができます。これらの手法を以下にまとめます。

  • コードを頻繁にコミットすることで、やがてインテグレーションが複雑になってくるという事態を防ぐことができます。
  • ビルドの失敗の大部分は、ソース・ファイルをコミットする前にローカルでビルドを実行することで簡単に防ぐことができます。
  • さまざまなフィードバックの手法を用いると、ビルド・ステータス情報がありきたりになって無視されるということがなくなります。
  • フィードバックに対応可能な人のみにフィードバックの対象を絞ることは、チームのメンバーにビルド問題を通知する方法としてより効果的です。
  • チーム・メンバーへのフィードバックを迅速化するための投資として、ビルド・マシンに余分にお金をかける価値はあります。
  • ビルド・パイプラインの作成は、ビルドの肥大化を抑える手段の 1 つです。

この記事で説明したアンチパターンは私がもっともよく目にするものですが、その他にも以下をはじめとするアンチパターンがあります。

  • 継続的イグノランス。ビルドが最小限のプロセスで構成されることから、ビルドは常に成功した状態になってしまいます。
  • 使用しているマシンでしか有効でないビルド。欠陥が発生してからそれを修正するまでの時間が長引く場合があります。
  • ボトルネックのコミット。ビルドに失敗する原因となりがちで、チームのメンバーがなかなか家に帰れなくなります。
  • 断続的なビルドの実行。迅速なフィードバックを妨げます。

2008 年は、継続的インテグレーションの最大限の活用を妨げる可能性のある別の CI アンチパターンを取り上げます。次の記事もお見逃しなく。

参考文献

学ぶために

  • Continuous Integration: Improving Software Quality and Reducing Risk』(Paul Duvall 他、Addison-Wesley Signature Series、2007年): さまざまな言語とプラットフォームでの 40 を超える CI 慣例を紹介しています。
  • Spot defects early with Continuous Integration」(Andrew Glover 著、developerWorks、2007年): このチュートリアルでは、Andrew Glover が継続的インテグレーションの基本的側面を検討し、選り抜きのオープン・ソース技術を使って CI プロセスをセットアップする方法をガイドしています。
  • Continuous Integration」(Martin Fowler、martinfowler.com): Fowler による、独創性に富んだ継続的インテグレーションについての記事です。
  • Continuous feedback」(Paul Duvall 著、developerWorks、2006年11月): ソース・コードが変更されるたびに即座にフィードバックを入手する方法を学んでください。
  • Is Pipelined Continuous Integration a Good Idea?」(infoq.com、2007年9月): 代表的な CI 支持者たちはビルド・パイプラインを重視しています。
  • 万人のためのオートメーション」(Paul Duvall、developerWorks): この連載のすべての記事を読んでください。
  • developerWorks Java™ technology ゾーン: Java プログラミングのあらゆる側面を網羅した記事が、豊富に用意されています。

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

  • Ambient Orb Ant task: この Ant タスクに従って、Orb の色をビルド・ステータスに応じて変えてください。

議論するために

  • Improve Your Java Code Quality ディスカッション・フォーラム: このディスカッション・フォーラムでは、developerWorks の常連寄稿者 Andrew Glover がコード品質の改善を重点に、コンサルタントとして豊富な専門的知識を提供しています。
  • developerWorks space: Accelerate development: developerWorks のコントリビューターとしてお馴染みの Andrew Glover がホストを務める、開発者テスト、継続的インテグレーション、コード・メトリック、そしてリファクタリングに関するあらゆるものを網羅したワンストップ・ポータルです。

コメント

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=282155
ArticleTitle=万人のためのオートメーション: 継続的インテグレーションのアンチパターン、第 1 回
publish-date=12042007