构建脚本和CI服务器之间的功耗权衡

Question

构建脚本和CI服务器之间的功耗权衡

antjenkinsgradlecontinuous-integrationbamboo

3

尽管这个问题特别涉及Gradle和Bamboo，但它实际上是关于任何构建系统（Ant/Maven/Gradle等）和任何CI工具（Bamboo/Jenkins/Hudson等）的问题。

我一直以为CI构建的目的是：

1.从VCS检出代码 2.运行构建脚本（Gradle等） 3.将二进制文件（WAR等）部署到环境中

因此，所有的内部细节和重要工作（运行自动化测试、代码分析、测试覆盖率、编译、Javadocs、打包等）都应该在构建脚本中完成。

但是Bamboo似乎允许您将这些重要工作从构建脚本中分离出来，并放到Bamboo本身中。在Bamboo中，您可以添加构建阶段并将其分解为任务。每个任务都像Ant任务一样原子且基本。

因此，这让我想：应该让CI工具拥有多少权力？哪些典型的构建脚本功能应该转移到Bamboo/CI？例如，我应该从Gradle任务还是从Bamboo任务进行编译？所有任务/阶段都是如此。

由于某种原因，我认为这与是否使用存储过程或将数据处理全部放在应用程序层面上是同样的问题。每种方法的优缺点是什么？

- AdjustingForInflation

2个回答

1

个人而言（使用现今的工具），我会采取务实的方法。我会尽可能多地在构建端完成工作（从自动化角度来看显然更好），剩下的（例如在不同机器上分配工作）由CI服务器完成。任何开发人员想要在自己的机器上完成的事情都应该在构建层面上进行自动化。至于你提供的具体步骤，我通常会从CI服务器检出代码，并从构建中部署二进制文件。我会尝试使每个CI作业看起来都相同，以相同的方式调用构建工具（例如gradlew ciBuild）。

在Bamboo中，您可以添加构建阶段并将阶段分解为任务。每个任务都像Ant任务一样原子/基本。

在某种程度上，这种功能重叠是自然的，因为构建工具和CI服务器都不能假设对方的存在，并且两者都希望提供尽可能完整的解决方案。

出于某些原因，我认为这与是否使用存储过程或将数据处理全部放在应用程序层面上是同一个问题。

这不是不公平的比较，因此意见将是多样化、上下文化和微妙的。

免责声明：我是Gradle（ware）开发人员。

- Peter Niederwieser

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Slav · Accepted Answer

底部有 TL;DR（总结）。

我的经验是使用 Jenkins，所以示例将与此相关。

任何构建系统（无论是 CI 服务器还是构建脚本）的一个要点是它应该稳定、简单且自包含，以便未经培训的前台接待员（具备打印说明和适当凭据）可以执行它。

易用性和可重复性

基于上述内容，人们可能认为构建脚本会胜出。但并不总是如此。就像前台接待员的例子一样，这取决于易用性和可重复性。

如果一个构建脚本有相互依赖的构建目标，只有在正确的顺序下才能工作，依赖于预先提供的属性文件，在构建之前必须进行调整以适应正确的分支，依赖于环境变量，但没有人记得是谁最初创建的，并且需要获取 SCM 修订号，必须查看过去一个月的提交日志... 这与可以通过单个按钮触发的 Jenkins 作业毫无区别。

同样，Jenkins 工作流可能依赖于多个相关作业，每个作业在构建之前都需要手动预配置，并且需要从一个地方上传工件到另一个地方... 这是没有接待员会做的。

因此，在这一点上，一个自包含的良好构建脚本，只需要 ant build 命令就可以从头到尾完成所有操作，就像只需要按下 build now... 按钮的 Jenkins 作业一样好。

自包含的

很容易认为，由于Jenkins最终会调用构建脚本的至少一部分（比如ant compile），因此Jenkins正在将构建脚本“分隔”成多个步骤，从而摆脱自包含性。
然而，相反地，你应该将整个Jenkins作业配置视为单个XML文件（顺便说一句，它可以通过SCM存储和版本化，就像构建脚本一样）

因此，在这一点上，无论整个构建逻辑是在单个构建文件还是单个XML作业配置文件中，都可以在正确完成时是自包含的。

你所熟悉的事物

在大多数情况下，问题归结为你所知道的东西。

有些人发现使用Jenkins UI来直观地安排他们的构建工作流、报告、发送电子邮件和归档（对于任何无法满足要求的内容，可以找到插件）更容易。对于他们来说，弄清楚构建脚本语言比在UI中尝试更耗费时间。
另一些人更喜欢知道他们构建脚本的每一行代码具体做了什么，他们不愿意将控制权交给被UI混淆的某个外部代码片段。

这两种观点都有利有弊，取决于质量-时间-预算三角的各方面考虑。

演讲内容

到目前为止，情况已经比较平衡了。然而：

我的Jenkins会通过电子邮件发送详细的HTML报告，其中包含作业页面链接，并直接发送给（不精通技术的）CEO。他可以查看最新构建列表，以及每个构建的SCM更改，链接到为每个构建修复的JIRA问题（所有相关位置的超链接）。他可以选择具有所需更改集的构建，然后在他刚刚用于查看所有这些信息的iPad上单击“安装iOS软件包”。与此同时，我可以转到同一作业页面，并查看每个日志的构建日志和工件，检查构建时间趋势，并比较失败和成功作业之间使用的参数（我不必编写任何

 echos 来显示它，因为Jenkins会为您完成所有这些操作）
使用构建脚本，即使将输出重定向到文件中，你是否会将其发送给（不精通技术的）CEO？不太可能。但是等等，你非常了解这个“魔鬼”。几个快速的更改和黑客攻击，几杯红牛......数月的无私工作（大多数是在下班后）后......你创建了一个构建脚本，将创建并启动Web服务器，准备HTML报告，收集统计数据和历史记录，向所有相关人员发送电子邮件，并像Jenkins一样发布所有内容在一个网页上。（哦，如果人们能看到你在构建脚本中逃避和清理所有那些HTML内容所做的所有魔术）。但是等等......这仅适用于单个项目。
所以，喝了一整箱红牛之后，你成功地将它变得通用，可以用于构建任何项目，并创建了另一个 Jenkins/Bamboo/CI 服务器。
恭喜您。起个名字，推广它，赚点钱吧，因为这个终极的构建脚本现在成了另一个像 Jenkins 的 CI 解决方案。



TL;DR:

如果CI服务器可以简单直观地配置，以至于接待员都能运行构建，并且配置可以自包含（通过CI服务器使用的任何存储方法）并在SCM中进行版本控制，则所有问题都归结为质量-时间-预算三角形。

如果你没有太多的时间和预算来学习CI服务器，你仍然可以通过采用CI服务器组织内容的方式极大地提高质量（至少是演示文稿的质量）。

如果你有无限的时间和预算，那么请务必自己创建一个带有构建脚本的Jenkins。

但考虑到“无限”的部分相当不现实，我会尽可能地采用CI服务器。是的，这是一种变化。然而，花费一点时间学习CI服务器以及它如何将构建流程的不同部分分隔或分解成任务，这些时间花费可以大大提高质量。

同样地，如果你没有时间和/或预算，弄清所有插件/任务等的怪癖以及它们如何组合在一起只会降低你的整体质量，甚至会拖累时间/预算。在这种情况下，使用CI服务器仅满足触发现有构建脚本所需的最低限度。但在某些情况下，“最低限度”甚至不比首次不使用CI服务器好。当你处于这种情况时...问问自己：


你为什么要首先使用CI服务器？