Rakeは、makeやantと同様の目的を持つビルド言語です。makeやantと同様にドメイン固有言語ですが、この2つとは異なり、Ruby言語でプログラムされた内部DSLです。この記事では、rakeを紹介し、このウェブサイトを構築するためにrakeを使用した結果、明らかになったいくつかの興味深い点について説明します。依存関係モデル、合成タスク、カスタムビルドルーチン、ビルドスクリプトのデバッグなどです。

Bruce Eckelの最近の投稿でのantとmakeに関する記事を読んで、ビルド言語に関する私の考えを共有したいと思いました。antとmakeはどちらもビルドがどのように行われるかを指定します。これらはビルドを記述するための言語です。どちらも非常に広く使用されており、成功を収めています。しかし、どちらも制限に突き当たります。大規模なシステムでは、ant/makeファイルを他のプログラムから生成しているのをよく見かけます。

自動化されたビルドとテスト環境の課題の1つは、フィードバックを迅速に得るためにビルドを高速化したい一方で、包括的なテストには時間がかかるということです。デプロイメントパイプラインは、ビルドを段階的に分割することで、この問題に対処する方法です。各段階は、通常、余分な時間と引き換えに、信頼性を高めます。初期段階ではほとんどの問題を検出して迅速なフィードバックを提供し、後の段階ではより遅く、より徹底的な調査を行います。デプロイメントパイプラインは継続的デリバリーの中核をなすものです。

自動構成ツール（CFEngine、Puppet、Chefなど）を使用すると、サーバーをどのように構成するかを指定し、新規および既存のマシンをコンプライアンスに準拠させることができます。これにより、脆弱なスノーフレークサーバーの問題を回避できます。このようなツールは、必要に応じて破棄して再構築できるフェニックスサーバーを作成できます。イミュータブルサーバーは、このアプローチの論理的な結論であり、一度デプロイされたら決して変更されず、新しい更新されたインスタンスに置き換えられるだけのサーバーです。

ここ数日、同僚のJulian Simpsonによる進行中の記事をレビューしています。彼はantファイルの リファクタリングについての記事を書いています。ジュリアンは、当社の「デプロイメント担当者」の1人で、アジャイル指向の作業習慣をシステムのデプロイに適用する役割を担っています。これを行うにあたり、ジュリアンはantビルドスクリプトの厄介な問題に数多く遭遇しています。彼の記事は、その混乱を解消するための彼のお気に入りの方法をいくつかうまく説明しています。

継続的インテグレーションの支持者が前提とするものの一つは、ビルドは再現可能であるべきだということです。これは、いつでも、作業中のシステムの古いバージョンを取り出して、当時とまったく同じようにソースからビルドできる必要があるということです。

makeを使用してビルドを行う場合、出力ファイルと入力ファイルの変更日を比較することで、作業を行う必要があるかどうかを判断します。（a.outはfoo.cに依存する）コンパイルのような場合はうまくいきますが、出力がわかりにくい場合があります。