虽然这个问题特别涉及Gradle和Bamboo，但它确实是关于任何构建系统（Ant / Maven / Gradle / etc。）和任何 CI工具的问题（竹/詹金斯/哈德森/等）。
我总是认为CI构建的目的是：
因此，所有的内容和繁重的工作（运行自动化测试，代码分析，测试覆盖，编译，Javadocs，打包等）都是在构建内部完成的。
但Bamboo似乎允许你打破这种繁重的编译并进入Bamboo本身。在Bamboo中，您可以添加构建阶段并将阶段分解为任务。每个任务都像Ant任务一样具有原子性/基本性。
所以它让我思考：一个人应该赋予CI工具多少权力？应该将哪些典型的buildscript功能转移到Bambooo / CI？例如，我应该从Gradle任务还是Bamboo任务编译？所有任务/阶段也是如此。
出于某种原因，我将此视为与是否使用存储过程或将数据处理全部放在应用程序层相同的问题。每种方法的优缺点是什么？
答案 0 :(得分：1)
TL; DR在底部
我的经验是詹金斯，所以这些例子与此有关。
任何构建系统（无论是CI server还是buildscript）的一件事是，它应该是稳定，简单和独立的，以便未经训练的接待员（带有印刷说明和适当的凭据） ）可以做到。
基于以上所述，人们会认为buildcript获胜。 并非总是。与接待员的例子一样，它关于易用性和易于再现性。
如果一个buildscript具有只能按正确顺序工作的相互依赖的构建目标，那么依赖于必须在构建之前针对正确分支进行调整的预先提供的属性文件，依赖于没有人记住的环境变量首先创建，并提供SCM修订号，必须通过查看上个月提交的日志来获得...这绝不比一个可以用单个触发的Jenkins工作更好按钮。
同样，Jenkins工作流可以依赖于多个依赖作业，每个作业都是在构建之前手动预先配置的，并且需要从一个地方上传到另一个地方的工件......没有接待员会这样做。
所以，在这一点上，只需要ant build命令从头到尾执行所有操作的自包含良好的构建脚本就像只需要build now...按钮的Jenkins作业一样好被压了。
很容易想到，由于詹金斯（在某些时候）最终会调用至少一部分的构建文件（比如说ant compile），因此詹金斯会将这些内容与＃34;区分开来。 buildcript分为多个步骤，从而脱离了自足。
但是，您应该缩小一个级别，并将整个Jenkins作业配置视为单个XML文件（顺便说一句，可以像生成器一样通过SCM存储和版本化）< / p>
因此，此时，如果整个构建逻辑位于单个构建文件或单个XML作业配置文件中，则无关紧要。如果做得好，两者都可以自成一体。
在大多数情况下，归结为你所知道的。
有些人发现使用Jenkins UI更容易直观地安排他们的构建工作流程，报告，电子邮件和存档（以及任何不符合要求的内容，找到一个插件）。对于他们来说，找出构建脚本语言比在UI中尝试它更耗时。
其他人更愿意确切地知道他们的构建脚本的每一行都做了什么，并且不喜欢控制由UI混淆的一些外来代码。
这两点都有各方面的优点Quality-Time-Budget三角形
到目前为止，事情已经或多或少地平衡了。但是：
我的Jenkins将通过电子邮件发送详细的HTML报告，其中包含指向工作页面的链接，并将其直接发送给（非技术娴熟的）CEO。他可以查看最新版本的列表，以及每个版本的SCM更改，将他链接到为每个版本修复的JIRA问题（所有超链接到相关位置）。他可以使用他想要的一组更改来选择构建，然后单击＆＃34;安装iOS软件包＆＃34;他刚用iPad查看所有这些信息。同时，我可以转到相同的作业页面，查看每个日志的构建日志和工件，检查构建时间趋势，并比较失败和后续作业之间使用的参数（我没有必要写任何echos显示它，它只是那里，因为詹金斯为你做了这一点）
使用buildscript，即使您将输出传输到文件，您是否会将其发送给您（非技术娴熟）的CEO？不太可能。但是等等，你知道这个恶魔非常好。一些快速的变化和黑客，结合红牛......以及几个月不讨好的工作（大多数是在下班后）...你已经创建了一个buildcript，它将创建和启动一个网络服务器，准备HTML报告，收集统计数据和历史，发送电子邮件给所有相关人员，并在网页上发布所有内容，就像詹金斯一样。 （哦，如果人们只能看到你所做的所有魔法逃脱并清理了buildcript中的所有HTML内容）。但是等等......这只适用于单个项目。
所以，以后完整的红牛案例，你已经设法使它足够普遍来建立任何项目，而你已经创造了......
祝贺。想出一个名字，推销它，并赚取一些现金，因为这个终极版本只是詹金斯的另一个CI解决方案。
<小时/>
如果可以简单直观地配置CI服务器，以便接待员可以运行构建，并且只要配置可以是自包含的（通过CI服务器使用的任何存储方法）并在SCM中进行版本控制，那么所有归结为质量 - 时间 - 预算三角形。
如果您没有时间和预算来学习CI服务器，您仍然可以大大提高质量（至少在演示文稿中） ）通过采用CI服务器的组织方式。
如果您有无限的时间和预算，请务必使用制作工具制作自己的Jenkins。
但考虑到＆＃34;无限制＆＃34;部分是不切实际的，我会尽可能地接受CI服务器。是的，这是一个变化。然而，在学习CI服务器以及它如何划分或分解构建流程的不同部分的任务方面投入了一点时间，这段时间花费了很长的时间来提高质量。
同样，如果您有没有时间和/或预算，找出所有插件/任务/等的怪癖以及它们如何结合在一起只会降低您的整体质量，或者甚至用它来拖延时间/预算。在这种情况下，请使用CI服务器，以便触发现有的构建脚本。但是，在某些情况下，＆＃34;最低限度＆＃34;最好不要首先使用CI服务器。当你在这个地方时......问自己：
为什么首先需要CI服务器？
答案 1 :(得分：0)
就个人而言（以及今天的工具），我采取务实的态度。我在构建方面做了尽可能多的事情（从自动化的角度来看显然更好），以及CI服务器上的其余部分（例如跨机器的工作分配）。开发人员可能想要在他自己的机器上做的任何事情都应该在构建级别上自动完成。至于你给出的具体步骤，我通常会检查CI服务器中的代码，并从构建中部署二进制文件。我尝试使每个CI工作看起来都一样，以相同的方式调用构建工具（例如gradlew ciBuild）。
在Bamboo中，您可以添加构建阶段并将阶段分解为任务。每个任务都像Ant任务一样具有原子性/基本性。
在某种程度上，功能上的这种重叠是很自然的，因为构建工具和CI服务器都不能假设另一个存在，并且两者都希望提供尽可能完整的解决方案。
出于某种原因，我将此视为与是否使用存储过程或将数据处理全部放在应用程序层相同的问题。
这不是一种不公平的比较，因此意见将具有多样性，语境和细微差别。
免责声明：我是Gradle（ware）开发人员。