
持续集成(CI)和/或持续交付(CD)如今已成为软件项目的标准做法。有许多构建服务器,如 Azure DevOps、TeamCity、Jenkins 和 Cruise Control.Net。这些服务器大多使用专有语言来定义构建步骤。但是,将构建步骤编码为专有语言真的是一件好事吗?
有些应用程序很简单,只有几个构建步骤,而其他应用程序则更复杂,有许多构建步骤。当您使用专有语言定义构建步骤时,构建步骤越复杂(在复杂性或数量上),您就越依赖于构建平台。当您想要切换构建平台时,这就成了一个问题。例如,您在本地数据中心使用 JetBrain 的 TeamCity,但公司决定迁移到云端。现在您必须重写构建脚本,因为新的云平台不支持 TeamCity。
与其使用专有语言编写构建脚本,不如考虑使用构建框架。
构建框架有两个好处:
- 允许在构建平台之间进行移植。
- 允许您将构建脚本与应用程序代码一起进行版本控制。
平台之间的可移植性为您提供了以最小努力在构建平台之间迁移的灵活性。在新的构建平台上总会有一些配置工作,但构建框架可以保持工作量较低。
在我看来,构建框架最大的好处是能够将构建脚本与应用程序代码一起签入和版本控制。能够从源代码控制历史记录的任何时间点拉取代码并构建该代码,这一选择完全值得构建框架的任何缺点。
在 .Net 领域有两个流行的框架:Cake 和 Nuke Build。这两个框架都已经存在了一段时间。我使用过 Nuke Build 并且很喜欢它。我听说过关于 Cake 的很多好评,建议您在决定哪个框架最适合您的项目之前先了解一下它。
所以下次您为应用程序创建新的构建定义时,请考虑使用构建框架并将其与您的应用程序一起签入源代码控制。
作者:Chuck Conway 专注于软件工程和生成式人工智能。在社交媒体上与他联系:X (@chuckconway) 或访问他的 YouTube。