ビルドフレームワークを使用する利点

継続的インテグレーション（CI）および/または継続的デリバリー（CD）は、最近のソフトウェアプロジェクトでは標準となっています。Azure DevOps、TeamCity、Jenkins、Cruise Control.Netなど、多くのビルドサーバーがあります。これらのサーバーのほとんどは、ビルドステップを定義するために独自の言語を使用しています。しかし、独自の言語でビルドステップを体系化することは良いことなのでしょうか？

一部のアプリケーションは、少数のビルドステップでシンプルですが、他のアプリケーションは多くのビルドステップを持つより複雑なものです。独自の言語でビルドステップを定義する場合、ビルドステップが（洗練度や数において）複雑になればなるほど、ビルドプラットフォームとの結合度が高くなります。これは、ビルドプラットフォームを切り替えたい場合に問題となります。例えば、オンプレミスのデータセンターでJetBrainのTeamCityを使用していたが、会社がクラウドに移行することを決定した場合、新しいクラウドプラットフォームでTeamCityがサポートされていないため、ビルドスクリプトを書き直す必要があります。

独自の言語でビルドスクリプトを書く代わりに、ビルドフレームワークの使用を検討してください。

ビルドフレームワークには2つの利点があります：

1. ビルドプラットフォーム間での移植性を可能にする
2. アプリケーションコードと一緒にビルドスクリプトをバージョン管理できる

プラットフォーム間の移植性により、最小限の労力でビルドプラットフォーム間を移動する柔軟性が得られます。新しいビルドプラットフォームでは常にいくらかの設定が必要ですが、ビルドフレームワークはその労力を低く抑えます。

私の意見では、ビルドフレームワークの最大の利点は、アプリケーションコードと一緒にビルドスクリプトをチェックインしてバージョン管理できることです。ソース管理の履歴の任意の時点からコードを取得し、そのコードをビルドできるオプションを持つことは、ビルドフレームワークのどんな欠点よりもはるかに価値があります。

.Net分野では2つの人気のあるフレームワークがあります：CakeとNuke Buildです。両方のフレームワークは長い間存在しています。私はNuke Buildを使用したことがあり、気に入っています。Cakeについても素晴らしい評判を聞いており、プロジェクトに最適なフレームワークを決定する前に検討することをお勧めします。

次回アプリケーション用の新しいビルド定義を作成する際は、ビルドフレームワークを使用し、アプリケーションと一緒にソース管理にチェックインすることを検討してください。