A build converts source code into a runnable program. Depending on the computer language and environment, this may mean you’re compiling source code and/ or bundling images and other resources together as needed. The scripts, programs, and technologies used by your compile and resource bundling are all combined to create the build system.
ビルドは実行可能プログラムにソースコードを変換します。コンピュータの言語（プログラミ具言語）と環境によって、これはソースコードのコンパイル及び又は必要に応じて複数の画像や他のリソースをバンドルすることを意味します。
バンドル：束ねる、まとめる
スクリプト、プログラム、およびコンパイルやリソースバンドルで使用される技術は、ビルドシステムを作成するためにすべて結合されています。
リソースバンドル：ロケールに応じてリソースが自動的に決定される仕組み
Now remember we're not talking about compiling/ building within your IDE. For the most part, you do not want to use your personal developer IDE to compile the project, even if you‘re the only one using it (see Practice 1, Develop in a Sandbox, on page 17 if this sounds odd to you). We’re talking about a build on your own machine that parallels the “official” build on the build machine. Here’s a little story to explain why.
今、IDEでのコンパイル/ビルドについて話していないことを念頭においてください。
たいていは、仮にそれを使うのが自分だけだったとしても、個人用のIDEでプロジェクトをコンパイルしたいとは思わないだろう。（これがおかしいと思う場合には17ページのPractice 1, Develop in a Sandboxを参照してください）
ここで述べているのは、ビルドマシンによる「公式」ビルドと並行している個人用のマシンでのビルドについてです。
Billy is ready to build his product, so he fires up his IDE and opens what he believes to be the right project. He asks the IDE to rebuild his project. When the IDE is done, he exits and copies the program to his installer directory. He then opens up his install program, points it at the program, and tells it to build an installer.
ビリーは彼の製品をビルドする準備が整ったので、彼のマシンのIDEを起動し、彼は間違いがないプロジェクトであると信じているものを開きます。彼はプロジェクトをリビルドするためにIDEを操作します。 IDEの処理が終わると、彼はIDEを抜けて、彼のインストーラーディレクトリにプログラムをコピーします。彼はその後、彼のインストールプログラムを開き、プログラムでそれを指し、インストーラをビルドするためにそれを伝えます。
Once the installer is built, he runs it to make sure it works. The installer immediately crashes. Billy remembers that he has forgotten to copy the latest version of the third—party Widgets that his product depends on. So he copies the latest version of Widgets into his installer directory. After he has built the program a second time, he realizes he forgot to copy over the latest version of the graphics his program uses. . . .
インストーラがビルドされると、彼はそれが動作することを確認するためにそれを実行します。インストーラはすぐにクラッシュ。ビリーは彼が彼の製品が依存しているサードパーティ製のウィジェットの最新バージョンをコピーし忘れていることを思い出します。そこで彼は、インストーラのディレクトリにウィジェットの最新バージョンをコピーします。彼はプログラムをもう一度ビルドした後、彼は彼のプログラムが使用するグラフィックスの最新バージョンをコピーするのを忘れていたことに気づきます。
Feels like a marathon, doesn't it? Billy is having a long night and yet again putting in some more unpaid overtime and missing reruns of Buffy.
Bob is also building his product today. Bob goes to the folder containing his code and types a one—line command (for instance, ant build_installer or make all) to run 11.111 his build script. The script builds the product (automatically fetching everything the product depends on), builds an installer for it, and tests the installer. Bob is now done.
まるでマラソンのように感じませんか？ビリーは夜遅くまで作業を続け、またまたサービス残業をし、Buffyを再実行できていません。
(and missing reruns of Buffy. が訳せず)
ボブもまた、今日製品のビルドを行っています。ボブは彼のコードと、11111個のビルドスクリプトを実行するためのワンラインコマンド（例えばAntビルドインストーラーやmake）があるフォルダに移動します。スクリプトは製品をビルドし（自動的に製品が依存するものを取得する）、そのためのインストーラーをビルドし、インストーラーをテストします。
ボブは既に仕事を終えています。
Ant：、Javaベースのビルドツールです。理論的にはmakeの欠点がないmakeの一種。
You can see from these scenarios the difference between using an automated build system and assembling your product by hand. Billy made a lot of errors that Bob avoided by automating his build. The steps that Billy forgot to perform were done automatically for Bob by his script, which does things the same way every time.
これらのシナリオから、自動ビルドシステムを使う場合と、手作業で製品を組み立てる場合との差を見ることが出来ます。ビリーはボブが自動ビルドによって回避したたくさんのエラーを発生させました。ビリーがやり忘れた手順を、ボブは毎回同じことを行うスクリプトによって行いました。
While many people will see Billy working late and consider him to be the more dedicated employee, we would rather work with (or be!) Bob. ;Automating your process not only makes your steps more exact (and less likely to be error-prone) but also lets you leave work on time—like Bob.
多くの人は、ビリーは仕事が遅いと思い、彼のことをより専門的な労働者だと考えるだろうが、私たちはむしろボブと働きます（働きたい）。プロセスの自動化はステップを確実にする（そしてエラーが発生しにくくする）だけではなく、ボブのように時間通りに仕事から離れられるようにします。
You can build your product in a variety of ways. You could have a list of steps that looks something like this:
l. Compile your code.
2. Copy the compiled code to your installer program.
3. Move the latest copy of your third party libraries (e.g., database drivers and parsers).
4. Drop in your non-code files such as HTML and graphics.
5. Copy over your help files to the installer. ;
6. Build the installer.
様々な方法でビルドを行うことができます。次のような手順のリストを持つことが出来ます。
1. コードをコンパイルする
2. インストーラープログラムにコンパイルされたコードをコピーする
3. 最新のサードパーティ製ライブラリを移動する（例：データベースドライバやパーサ）
4. HTMLやグラフのようなコードではないファイルをドロップする
5. インストーラーにヘルプファイルをコピーする
6. インストーラーをビルドする
※「e.g.」は、ラテン語の「exempli gratia」の略で、英語で書けば「for example」。
You have a problem if you do anything by hand in your build or packaging process. The only question is whether you choose to invest the time to address the problem up front or you waste time performing the task by hand over and over and then deal with the problems that result from the inevitable mistake when a step is missed or blundered. The first option is a wise investment of your time in the early stages of a project. The second is a black hole. It will be a source of frustration, and problems for the life of your product. In other words, you’ll have to work much harder to build a solid house if you skimp on the foundation.
ビルドまたはパッケージングプロセスで、手作業で何かを行うと問題が発生します。唯一の問題は、事前に問題を処理するための時間を使うことを選択するか、手順を間違えるかやりそこなった時に、何度も何度も手作業でタスクを行う時間を無駄にして、避けられないミスの結果である問題を処理するかです。
Script builds on day one
スクリプトは初日に構築する
At a minimum, use a batch file or shell script to perform the build (there are better ways to do this, of course, and you'll start looking at those shortly).
最低でも、ビルドを行うためのバッチファイルかシェルスクリプトを使いましょう。（より良い方法が存在していて、もちろんまもなくそれらを見られます）
But wait! you cry, why can't I just use my IDE to perform these steps; for me? Well, you could, but here are the issues:
It’s unlikely that the build machine is using the same IDE (most IDEs make it cumbersome, or even impossible, to operate in a batch mode).
You would have to force your entire team—experts and beginners alike—to use the same IDE. Sometimes that’s acceptable, but many times it raises more problems than it solves.
Even when everyone uses the same IDE, it can be difficult to propagate changes in the development environment (a new library, a different compiler setting) to everyone.
だが待ってください。どうしてそれらの手順を行うのにIDEを使えないのか、というかもしれません。たしかにIDEを使うことは出来ますが、次のような問題があります
ビルドマシンが同じIDEを使っていることはまずない（多くのIDEはバッチモードでの操作が扱いにくいか不可能である）
熟練者から初心者まで含め、チーム全体に、同じIDEを使用することを強要しなければならない。これが許容される場合もありますが、多くの場合これによって解決されるよりも多くの問題を発生させます。
全員が同じIDEを使用している場合でも、開発環境（新しいライブラリや別のコンパイラ設定）が変化したことを周知することが難しい場合があります。
These problems aren’t insurmountable, but they are sticky. That’s why we find it much easier to separate the automation of the build from the IDE world. But it’s important that the build—in all its complexity—can be launched with a single command.
これらの問題が解決できないものではないが、厄介です。このため、IDEの世界からビルドの自動化を分離させたほうが簡単であると考えます。しかし、複雑なビルドが単一のコマンドで行えることは重要です。
If you can’t build your project with a single command, then most of the team won’t bother. As is true of most tasks, nobody will do it if it isn’t easy. One of the hallmarks of a great development effort is being able to build your project easily (and consistently) on every developer’s desktop.
もし単一のコマンドでプロジェクトのビルドが出来なくても、チームのほとんどは気にしないだろう。多くのタスクに当てはまることだが、簡単でないことは誰もしない。優れた開発作業の特徴の一つは、すべての開発者のデスクトップ上で簡単に（かつ一貫して）プロジェクトのビルドを行えることです。
Much as we’d like, it doesn’t always go that way. In one shop from our checkered past, they always built their product by hitting the Build button inside a specific IDE on a certain machine. Then the developer who had set up the build left the company. None of the remaining employees knew how to build the system without using the departed developer’s workstation and its “magic Build button.” The managers were shocked when we told them how the code was built—they had no idea.
我々が望むように、常にそうした方法を取ることはできません。我々の波乱にとんだ過去において、ある開発現場では彼らは常に特定のマシン上の特定のIDEのビルドボタンをおすことで製品を作っていた。そしてビルドのセットアップを行っていた開発者が会社を去った。残った労働者のうち、去っていった開発者のワークステーションと、それの魔法のビルドボタンなしでシステムをビルドする方法を知っているものは誰もいなかった。我々がどうやってコードをビルドするのか尋ねると、マネージャーはショックを受けた。彼らには見当もつかなかった。
Be sure you can build your product the same way on every workstation in the shop. If you don’t know how to build the product, the odds are good that no one else does either.
現場の全てのワークステーションにおいて、同じ方法で製品をビルドできるようにしてください。もしあなたがビルドする方法を知らなければ、他の人もそうである可能性が高いです。
Any machine can be o build machine
そのマシンもビルドマシンにできる。
In a pinch, any developer’s box can substitute for the build box by using the same (checked-in) scripts. The goal is that a build on any capable machine should be bit-for-bit identical with that of the build machine (except for things like time stamps, the IP address or name of the machine, etc.)
ピンチの時には、同じ確認済みのスクリプトを使用することで、どんな開発者の箱もビルドの箱の代わりにすることが出来ます。目標は、すべての能力のあるマシン上でのビルドは、ビルドマシン上のビルドとビット単位で同一であることです。（タイムスタンプやIPアドレス、マシンネームのようなものは除きます）
Build scripts don’t have to be very complicated. This example shows a complete and usable Ant script that's still pretty straight-forward and readable (despite the XML angle brackets).
ビルドスクリプトは、非常に複雑である必要はありません。この例では、完全で使用可能にもかかわらず、とても単純で読みやすいAntスクリプトを示します。
スクリプト（本文参照）
How Do I Get Started?
If you just inherited a new product without an automated build, you should take these steps immediately to get a build script in place:
1. Have a team member manually build the system while you take notes.
2. Define the individual build steps.
3. Pick a build tool but be prepared to revisit other options if this tool becomes too burdensome.
4. Incrementally script each step; eliminate manual operations one by one.
5. Run the script on another workstation. This step will catch any accidental workstation-specific code.
6. Now have another team member try to use the script without your help.
When you complete these steps, you will have a script that should work for everyone.
どのように始めたらよいですか？
あなただけの自動ビルドすることなく新しい製品を継承する場合は、適切にビルドスクリプトを取得するには、すぐにこれらの手順を取る必要があります。
1.あなたがメモを取る間、チームメンバーに手動でシステムをビルドさせる。
2.個々のビルドステップを定義する。
3.ビルドツールを選ぶが、このツールが非常に負担になった場合に他のオプションを再検討するために準備する。
4.段階的に各ステップのスクリプトを作り、マニュアル操作をひとつずつ潰す。
5.別のワークステーション上でスクリプトを実行する。このステップでは、偶発的なワークステーション固有のコードをキャッチします。
6.今すぐ他のチームメンバーにあなたの助けなしでスクリプトを使用させる。
これらの手順を完了すると、すべての人のために働くはずのスクリプトを持つことになります。
Am I Doing This Right?
If you're using your manual build system properly, you will be able to build your entire product:
With one command
From your Source Code Management system (SCM)
On any team member’s workstation
With no external environmental requirements (such as specific network drives)
If you have issues with any of these items, have another look at your build process.
私はこれを正しく行えていますか？
手動ビルドシステムを適切に使用している場合、製品全体をビルドできるようになります
一つのコマンドで
ソースコード管理システムから
他のチームメンバーのワークステーション上で
外部環境要求（例えば、特定のネットワークドライバなど）なしで
これらの項目のいずれかに問題がある場合は、ビルドプロセスをもう一度見直しましょう。
Warning Signs
Your build contains any manual steps.
Your build script has to be modified to rum on different machines.
Only a few team members know how to edit the build script.
警告サイン
ビルドに手動の手順が含まれている
ビルドスクリプトは、異なるマシンで実行するためには編集しなければいけない
極少数のチームメンバーしかビルドスクリプトを編集する方法を知らない
最終更新：2011年07月01日 14:44
