我们目前正在使用竹子来构建和测试我们的软件。现在，我们的构建计划只是一堆任务：执行此蝙蝠，执行蝙蝠等。
创建的蝙蝠等。碰巧的是，在数月/年，构建计划需要调整：
- 并行化工作
- 添加额外的工作
- 更改某些任务
但是，当我们尝试构建软件的较旧版本时，这将破裂。某些脚本（从竹任务中调用）在较旧版本中不存在。
在我以前的雇主中，我们使用了jenkins管道，其中构建和测试的内容只是来源存储库中的一个文件。
现在用竹子看，您可以使用竹子规格。从我阅读中，您可以创建规格文件，并且在运行此文件时，它将创建构建计划。但是我认为随着时间的推移更改构建计划（更改步骤）没有关系。
例如，开发的竹规范用于建立所有计划分支（例如拉请请求）。因此，如果您想更改勒奎斯特的构建，则首先需要将其合并为"开发"，"竹子规格"开发更新了构建计划。在合并之前不可能进行测试。
问题：如何在竹子中制作脚本化的构建图，在这里，每个分支都可以使用其他构建方式？
我们现在将其设置为：
- buildplan'product a'：计划分支：开发，发行版，释放，y
- buildplan'产品a pullrequest'：计划分支：功能/*
编辑：在7.0中支持：https：//confluence.atlassian.com/bamboo/bamboo/enhance-plan-plan-branch--configuration-996709304.html
旧答案：
我找到了Atlassian文档：https：//jira.atlassian.com/browse/bam-19620。他们称其为"分歧计划分支"。没有支持，有一个功能请求。
截至2019年1月15日：
Atlassian更新 - [2019年4月11日]大家好，
感谢您对这个问题的投票和想法。
我们完全理解你们中的许多人都依赖这一点 功能。
仔细考虑后，我们决定优先考虑[ 特征]在竹路线图上。我们希望在我们之后开始发展 当前项目已完成。
期望在接下来的6个月内听到我们进度的更新。
要了解如何审查您的建议，请参阅我们的更新 服务器功能建议的工作流程。
善意，
竹子团队
问题：如何在竹子中制作脚本构建计划？
要使脚本构建计划在竹子中，您必须使用竹规范。由于您已经熟悉Jenkins，因此通过自动化管道来使Bamboo Specs完全像Jenkinsfile一样工作。使用此功能的好处是，它生活在源代码中，并且您在源代码中对此文件进行的更改会自动更改您的计划（管道）（管道）时，否则竹制构建时。这就是我脚本在竹子中构建计划的方式：
- 我将我的bamboo.yml文件添加在我的存储库的根部。但是目前，我使用git子树，我的竹规范居住在那里。但是您不必这样做。以下链接为您提供了一种简单的方法。
- 将我的存储库链接到竹子
- 告诉竹子扫描回购中的竹子规格
- 进行提交并推动
https://confluence.atlassian.com/bamboo/tutorial-bamboo-specs-specs-yaml-stored-in-bitbucket-server-941616819.html
如果我将来必须对计划进行更改，请编辑竹子规格文件，然后提交并推动。
我有同样的问题，不幸的是必须经历不愉快的选择
backport构建脚本
这不一定是可行的，但是我设法使它起作用以某种方式为我的项目。
这个想法是：将构建脚本视为c＃/java interface，或者更好地为合同。
一旦您的分支机构没有提供重大变化，例如构建软件，例如您的桌面应用程序成为Web应用程序，或者您从Ant切换到Gradle，您可以处理此。
假设我的应用程序始终是jfrog文物上的jar应用程序，我已经确定了所有维护版本共有的以下步骤：
- 使用
javac构建所有模块的罐子 - 使用
gulp构建JavaScript资源 - 从存储库运行junit
- 洗礼💒用棘手的算法获得的版本编号
- 将工件推到Jfrog文物
因此，我的想法是我拿了我的蚂蚁构建脚本，并且主要重写它，以便在应用程序的不同版本上执行相同的任务。我开始从较旧版本中进行更改，而不再维护为锻炼。实际上，我的官方git分支看起来像release/x.y.z，其中SEMVER为x.y.z.k，并且从任何x.y.z版本的头部构建了较新的BugFix-Builds。
所以我取了release/3.10.0分支并重写了蚂蚁。我目前正在使用手动创建的竹计划进行测试
阶段：编译
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 =＆gt; release/3.10.1 =＆gt;release/3.10.2 ... release/3.11.2通过合并冲突
个人经验
今晚，我正在努力进行Junit测试工作，因为我还选择将测试框架退回到该项目的较旧版本。我接受一些测试会失败，因为较旧的和未维护的版本包含错误。对我来说，这是一种证明系统工作的方法。
的确，分歧是一个好主意，但是我被迫在办公室里使用竹子