连续集成和预集成

Question

我张贴了一个部分问题，一部分闲谈，希望它将产生讨论，并回答我的问题，这是更多的一系列要求，如果我是诚实的。

在我的工作场所，建筑是非常劳动密集的。这是因为我们的团队很小，人们怀疑自动化不可避免地会出错，因为我们在团队中没有足够的专业知识来正确地完成这一任务。我认为这是一个合理但有缺陷的论点。我身边确实有一位中层经理，他似乎很喜欢自动化的概念，并成功地使用了许多小型自动化功能。

我的目标是将一种自动构建环境与我们的发布系统联系在一起，这就要求管理人员生成各种文档。这是TickIT认证的要求，不需要协商。我想象的是产生一个(Windows)工作流--我们已经为它建立了IT基础设施，并且在全公司范围内都熟悉它--它促使经理们提交文档，这些文档必须提交才能生成和发布。我们不是一家软件公司，我们是一家销售软件的公司，所以这些特性需要被推广到非技术领域。

因此，总之，我们的用例应该类似于：

• 管理员检查任务跟踪器，并根据当前状态授权发布。
• 工作流程启动，缓存了当前的SVN修订版。
• 工作流要求项目经理提供一些pdf文档等，这些文档需要内置到安装包中。
• 工作流在集成管理器(如CruiseControl )上启动以前缓存的SVN修订版上的构建过程(我在这里包括了连续集成所做的一切，包括单元测试)
• 完整的安装包会自动安装在各种虚拟机上(整套受支持的操作系统和语言)，并提供给QA。
• 在QA完成注册后，安装包就会发布到web上。

当然，由于任何事情都不能正常工作，因此应该包括在任何时候“破坏”工作流并手动执行的能力，因为我们不希望一个愚蠢的机器阻止它的发布，因为它不能完成它的工作，而一点常识也能做到这一点。

有没有人有什么可以被认为是这类过程的案例研究，或者是否有任何关于它可能是多么简单或有挑战性，甚至它有多合适的评论？

Answer 1

我们最近为我们的一个客户解决了这个问题。我们的实现涉及以下组件(但您可以通过不同的工具实现相同的功能，这取决于您的组织)。

• JIRA工作流-编排流程(并捕获性能指标)、管理审批和跟踪审核历史记录。
• JIRA插件-通过CI服务器构建\部署\测试(Hudson\Jenkins)。侦听器:响应Hudson\Jenkins的状态更新
• Jenkins插件-与JIRA交互
• 构建管道插件 -管理Jenkins工作流
• 部署脚本-由Jenkins\Groovy编排

这听起来很复杂，但是很多这些工具都有很好的API可供使用，所以您可以在合理的时间框架内一起获得一个稳定的解决方案。

干杯,

杰夫

Answer 2

在对此做了一些研究之后，我花了几天时间在CruiseControl.NET上玩，因为它的可扩展性，看起来它可以完成我想要的所有事情。在构建结束时，没有任何障碍可以启动另一个插件来完成所有的部署和注销。有些需求是复杂的，需要不确定的时间，所以我认为像WWF这样的状态持久化是有价值的。我将不得不和我的同事们试验并提出这个问题。

Answer 3

以CloudMunch为例。CloudMunch提供了一个构建引擎(基于Jenkins)，在其之上构建进度工作流，在上面管理手动工作流，并提供干净的RBAC支持来管理您正在查看的内容。

免责声明:我在CloudMunch工作。