ソフトウェアにおけるbuildとは?

buildとは、人が書いたソースコードを、ソフトウェアの実行可能または配布可能な形に変える処理であり、またその結果でもあります。

"build"という語は二役を担います。コードをコンパイルしパッケージ化する行為と、その行為が生成するartifactの両方を指します。buildが何であるかを理解すると、CIが行うことの大半が明確になります。CIはその本質において、buildを実行するエンジンだからです。

処理としてのbuild

処理としては、buildはソースコードをコンピューターが実行できる何かに変換します。言語によっては、機械語やバイトコードへのコンパイル、別の言語へのトランスパイル、ファイルのバンドル、結果のパッケージ化を意味します。同じソースを、debugやreleaseなど異なる構成でbuildすることもできます。

artifactとしてのbuild

名詞としては、"build"はその処理の出力を指します。バイナリ、コンテナイメージ、JAR、圧縮バンドルなどです。各buildには通常、どのソースがそれを生成したかを正確に追跡できるよう、バージョンやcommit識別子のラベルが付けられます。このartifactこそが実際にdeployされるものです。

実例

Javaのサービスの場合、buildは依存関係をダウンロードし、ソースをクラスファイルにコンパイルし、コード生成があればそれを実行し、すべてをバージョンでタグ付けした単一のJARファイルにパッケージ化します。そのJARが"build"であり、サーバーへ出荷されるものです。

なぜbuildがCIで実行されるのか

buildは変更ごとにCIが最初に行うことです。コードがそもそもbuildできなければ、他のすべては意味を持たないからです。成功した再現可能なbuildは、テストとdeploymentの前提条件でもあります。CIはクリーンなマシンでbuildを実行し、たまたまローカルでだけ機能していた依存関係やステップを捕捉します。

良いbuildの条件

再現可能: 同じ入力は常に同じ出力を生みます。
速い: 速いフィードバックが開発者を頻繁に統合させ続けます。
追跡可能: すべてのbuildが特定のcommitへ対応づけられます。
クリーン: 残存するローカル状態からではなく、ゼロからbuildされます。

重要なポイント

buildは、実行可能なソフトウェアを生成する処理であると同時にその出力でもあります。
buildは再現可能で、速く、commitまで追跡できるべきです。
CIはクリーンなマシンでbuildを行い、ローカル限定の前提を捕捉します。