持续集成 (CI) 和/或 持续交付 (CD) 如今已成为软件项目的标准做法。有许多构建服务器,如 Azure DevOps、TeamCity、Jenkins 和 Cruise Control.Net。这些服务器中的大多数都使用专有语言来定义构建步骤。但是,用专有语言编写构建步骤是一个好主意吗?
有些应用程序很简单,只有几个构建步骤,而其他应用程序则更复杂,有许多构建步骤。当你用专有语言定义构建步骤时,构建步骤越复杂(无论是在复杂性还是数量上),你对构建平台的耦合就越紧密。当你想切换构建平台时,这就成了一个问题。例如,你在本地数据中心使用 JetBrain 的 TeamCity,但公司决定迁移到云端。现在你必须重新编写构建脚本,因为新的云平台不支持 TeamCity。
与其用专有语言编写构建脚本,不如考虑使用构建框架。
构建框架有两个好处:
- 允许在构建平台之间进行可移植性。
- 允许你将构建脚本与应用程序代码一起进行版本控制。
平台之间的可移植性使你能够灵活地在构建平台之间切换,只需付出最少的努力。在新的构建平台上总会有一些配置,但构建框架可以将工作量保持在较低水平。
在我看来,构建框架最大的好处是能够将构建脚本与应用程序代码一起签入和版本控制。能够从源代码控制历史记录中的任何时间点拉取代码,并让该代码构建成功,这完全值得构建框架的任何缺点。
在 .Net 领域有两个流行的框架:Cake 和 Nuke Build。这两个框架都已经存在了一段时间。我使用过 Nuke Build,很喜欢它。我听说过很多关于 Cake 的好评,我鼓励你在决定哪个框架最适合你的项目之前先看一下它。
所以下次当你为应用程序创建新的构建定义时,考虑使用构建框架,并将其与应用程序一起签入源代码控制。
作者:Chuck Conway 是一位 AI 工程师,拥有近 30 年的软件工程经验。他构建实用的 AI 系统——内容管道、基础设施代理和解决实际问题的工具——并分享他沿途的学习成果。在社交媒体上与他联系:X (@chuckconway) 或访问他的 YouTube 和 SubStack。