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

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

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

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

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

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

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

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

.NETスペースには2つの一般的なフレームワークがあります：CakeとNuke Buildです。両方のフレームワークはしばらく前から存在しています。私はNuke Buildを使用しており、気に入っています。Cakeについて素晴らしいことを聞いており、プロジェクトに最適なフレームワークを決定する前に、それを確認することをお勧めします。

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