竹脚本构建计划

Question

我们目前正在使用竹子来构建和测试我们的软件。现在我们的构建计划只是一堆任务：执行这个 bat，执行那个 bat 等等。使用 Bamboo UI 创建。

构建计划需要经过数月/数年的调整：

• 并行化作业
• 添加额外的工作
• 更改一些任务

但是当我们尝试构建旧版本的软件时，这会中断。一些脚本（从竹子任务中调用）在旧版本中不存在。

在我以前的雇主，我们使用 Jenkins 管道，其中构建和测试的内容只是源代码库中的一个文件。

现在有了竹子，您似乎可以使用 Bamboo Specs。从我读到你创建规范文件，当你运行它时，它将创建构建计划。但我看不出与随时间变化的构建计划（改变步骤）的关系。

例如，develop 的 Bamboo Specs 用于构建所有计划分支（例如 Pull Requests）。所以如果你想改变一个PullRequest中的build，你首先需要把它合并到develop中，develop的Bamboo Spec会更新Build Plan。在合并之前无法对此进行测试。

问题：如何在 Bamboo 中制定脚本构建计划，其中每个开发分支都可以有其他可能的构建方式？

我们现在将其设置为：

• 构建计划“产品 A”：计划分支：develop、release_x、release、y
• 构建计划“产品 A PullRequest”：计划分支：功能/*

Answer 1

编辑： 7.0 支持：https://confluence.atlassian.com/bamboo/enhanced-plan-branch-configuration-996709304.html

旧答案：

我找到了 Atlassian 文档：https://jira.atlassian.com/browse/BAM-19620。他们称之为“分歧计划分支”。 不支持，有功能请求。

截至 2019 年 4 月 15 日：

Atlassian 更新 - [2019 年 4 月 11 日] 大家好，

感谢您对此问题的投票和想法。

我们完全理解你们中的许多人都依赖于此 功能。

经过仔细考虑，我们决定优先考虑 [这个 功能] 在 Bamboo 路线图上。我们希望在我们之后开始开发 当前项目已完成。

期待在未来 6 个月内听到我们的最新进展。

要详细了解如何审核您的建议，请参阅我们更新的 服务器功能建议的工作流程。

亲切的问候，

竹队

Answer 2

问题：如何在 Bamboo 中制定脚本构建计划？

要在 Bamboo 中制定脚本化构建计划，您必须使用竹子规范。由于您已经熟悉 Jenkins，因此竹规范的工作方式与 Jenkinsfile 完全一样，可以自动化您的管道。使用它的好处是它存在于您的源代码中，并且您在源代码中对此文件所做的更改会在触发竹构建时自动更改您的计划（管道）。 这就是我在竹子中编写构建计划的方式：

1. 我在我的存储库的根目录下添加了我的竹子.yml 文件。但是目前，我使用 git subtree 并且我的竹子规格就在那里。但你不必这样做。以下链接为您提供了一种简单的方法。
2. 将我的仓库链接到竹子
3. 告诉竹子扫描回购中的竹子规格
4. 提交并推送

https://confluence.atlassian.com/bamboo/tutorial-bamboo-specs-yaml-stored-in-bitbucket-server-941616819.html

如果我将来必须对计划进行更改，我会编辑竹规范文件，然后提交并推送。

Answer 3

我遇到了同样的问题，不幸的是不得不经历一个不愉快的选择

向后移植构建脚本

这不一定在任何地方都可行，但我设法使其工作以某种方式用于我的项目。

想法是：将构建脚本视为 C#/Java interface，或者更好地视为合同。

只要您的分支机构在构建软件时没有提供重大更改，例如你的桌面应用变成了网络应用，或者你从 Ant 切换到 Gradle，你都可以处理。

假设我的应用程序始终是作为 JFrog Artifactory 上的 jar 发布的 Web 应用程序，我确定了所有维护版本共有的以下步骤：

• 使用javac构建所有模块的jar
• 使用gulp构建Javascript资源
• 从存储库运行 JUnit
• Baptize ? 通过复杂算法获得的带有版本号的工件
• 将工件推送到 JFrog Artifactory

所以我的想法是我采用了我的 Ant 构建脚本，并且大部分都重写了它，以便在不同版本的应用程序上执行相同的任务。作为练习，我从不再维护的旧版本开始进行更改。事实上，我的官方 Git 分支看起来像 release/x.y.z，其中 semver 是 x.y.z.k，并且更新的 bugfix-builds 是从任何 x.y.z 版本的头部构建的。

于是我拿了release/3.10.0 分支重写了Ant。我目前正在使用手动创建的 Bamboo 计划进行测试

阶段：编译

ant clean ivy-retrieve compile jar #builds the jar in a job
ant gulp-install gulp-prod zip #creates javascript resources

阶段：测试

ant run-junit

手动阶段：发布

ant baptize ivy-release #tags the artifact using ${bamboo.jira.version} and pushes to JFrog Artifactory

我要用 Yaml 做什么

由于构建脚本是相同的，但特定任务（例如 Java 编译器版本）可能会在不同版本中发生变化，我可以创建一个非常单一的 Yaml 脚本来管理它们的所有版本。

然后我将合并release/3.10.0 => release/3.10.1 => release/3.10.2 ... release/3.11.2 通过合并冲突

个人经历

今晚我正在努力使 JUnit 测试正常工作，因为我还选择将我的测试框架向后移植到项目的旧版本。我接受一些测试会失败，因为旧版本和非维护版本包含错误。对我来说，这是一种证明系统有效的方法。

确实，分支分支是个好主意，但我不得不在办公室使用 Bamboo 6