Build 为嵌入式软件构建（CI）服务器

我想问一下您在嵌入式系统构建服务器方面的经验。你在用什么（如果有的话），什么是好的方面和坏的方面

我们主要为没有操作系统的微控制器开发

现在我正在尝试使用Jenkins，我的构建正在运行。但我对项目结构有一些问题。当我希望所有插件都能工作时，我需要的是扁平的工作结构。但我们几乎没有并行开发的项目，然后工作视图开始变得混乱。 我尝试了文件夹，但是一些插件停止了工作

我想构建一个管道，它按顺序运行，但内部有并行作业。提交阶段有：编译、lint检查、样式检查、单元测试。所有这些都可以并行运行，当所有这些都成功时，下一阶段将执行

此时我需要从Build server获得什么：

• 建立管道支持
• 基于LDAP的用户授权
• 并行作业执行
• 分层项目（项目/配置组）
• 来自xUnit、Lint、编译器警告、Robot框架的报告
• 从机/代理支持，从机标签

• 基于ldap组的权限

• 每个组/项目的权限

我愿意接受任何建议，开源和商业。 我在看录像带上的竹子看起来很漂亮，但我还没试过

我们有两个开发团队，他们正在开发不同的项目。为团队分组项目并为组分配权限可能会很好。一个组的成员不应修改其他组的生成。但“拥有”比“必须拥有”更美好

TeamCity

我试着使用TeamCity。构建管道比在Jenkins中更容易，只需单击添加步骤

我发现有一件事很难，那就是在一个配置中并行执行步骤。例如，在提交之后，我希望并行运行Lint、单元测试、编译以节省一些时间。我发现了，但它使管道更难查看和维护

TeamCity支持项目中的多个配置，以解决作业分组问题。我没有找到对项目进行分组的选项。

是JetBrains提供的基于Java的免费CI服务器。我们一直在非常成功地使用它（用于非常不同的项目），我会毫无保留地向您推荐它。根据您的每项要求：

• 生成管道在生成配置中配置为一系列步骤。一个项目可以有任意数量的配置，而这些配置又可以有任意数量的步骤
• 完全支持LDAP集成
• 构建管道可以并行执行。TeamCity代表负责构建代理，这些代理通常是不同的服务器，具有执行构建配置步骤所需的所有工具（框架等）。TeamCity的免费版本附带三个代理的许可证，因此最多可以有三个构建并行运行。额外的代理可以以象征性的费用获得许可
• 我理解“分层项目”是指一个构建管道的完成将自动触发后续管道的启动。这是受支持的，为了保持一致性，可以在阶段之间传递内部版本号
• XUnit拥有一流的支持。Lint/compiler报告可以保存为构建的“工件”，以便于以后查看。本质上，许多框架在TeamCity中都有内置支持，对于其他一切，您都可以执行任意shell命令，其输出可以保存为工件或在后续构建步骤中使用
• 如上所述，从属/代理支持是TeamCity模型的核心

---

所有这些都是高度可配置和定制的。我们已经能够与TeamCity一起做很多多样、复杂的事情，这对我们来说是完全稳固和稳定的。而且它看起来也不错——服务器仪表板以一种易于理解的方式排列信息

免责声明：我为Atlassian工作，所以我有点偏见

用竹子配置构建管道非常容易。竹子是按计划经营的→ 阶段→ 职务结构，按从高到低的顺序列出。看看这本书

竹子中的每个项目都包含一系列计划。计划由一个或多个阶段组成。阶段按顺序运行，由一个或多个作业组成。作业并行运行，由一个或多个任务组成（任务按顺序运行，但可以放在单独的作业中，以便它们并行运行并加快构建时间）。竹子中的代理是执行构建步骤的机器或服务。整个作业将在单个代理上执行。您可以阅读更多有关代理的信息。至于从属标记，使某些代理专门绑定到某些构建或项目的能力在新功能的短名单上

要回答您的其他问题：

• 基于LDAP的用户授权/基于LDAP组/项目的权限：您可以连接到外部LDAP服务器以管理用户和权限。竹有一个组功能，或者如果您的团队正在使用JIRA，您可以利用JIRA组设置全局权限、计划权限，还可以指示哪些用户将收到关于计划生成结果的通知。全局权限控制谁可以访问生成计划和服务器，而计划权限控制谁可以对计划及其作业执行特定操作

• 分层项目（项目/配置组）：Bambol不支持父级和子级计划结构。有几种方法可以设置生成触发。其中之一是基于其他生成的触发器，也就是说，计划生成由其他计划的先前成功生成触发，或者如果其他指定的计划正在成功生成。示例：如果计划A构建成功，它将自动触发