持续集成和预集成

Question

我发布了一个部分问题，希望它能够产生讨论并回答我的问题，如果我诚实的话，这是更多的一系列要求。

在我的工作场所，建筑物非常劳动密集。这是因为我们的团队非常小，并且怀疑自动化将不可避免地出问题，因为我们没有团队中的专业知识来正确执行。我认为这是一个合理的，但有缺陷的论点。我的确有一位中层管理人员，他似乎喜欢自动化的概念，并且已经成功地使用了许多小型自动化功能。

我打算做的是在我们的发布系统中绑定一种自动化的构建环境，这需要管理员制作各种文档。这是TickIT认证的一项要求，不适用于谈判。我想象的是制作一个（Windows）工作流程 - 为此我们建立了IT基础架构，并且在整个公司范围内都很熟悉 - 它会提示管理人员必须提交的文档，以便构建和发布。我们不是一家软件公司，我们是一家销售软件的公司，所以这些功能需要在非技术方面进行推广。根据当前状态

工作流程揭开序幕

• 经理回顾了任务追踪器，并授权释放，已经缓存在当前SVN版本
：

因此，在总结，我们的用例看起来是这样的

• 来自项目经理的工作流需求需要内置到安装包中的许多pdf文档等
• 工作流在集成管理器（如CruiseCont）上激发先前缓存的SVN修订版上的构建过程rol（我在此包括持续集成所做的所有事情，包括单元测试）
• 已完成的安装包会自动安装在各种虚拟机（支持的完整操作系统和语言）上，并且可用于QA
• 在从QA完成签收，安装包释放到网络

当然，因为从来都没有正常工作的能力，为“突破”的工作流程，并随时手动进行，应包括在内，因为我们不要让一台愚蠢的机器发挥不了它的作用，因为一些常识可以做到这一点。

有没有人有任何可以被视为这种过程的案例研究，或任何有关它可能是多么简单或具有挑战性的评论，或者它是多么恰当？

Answer 1

我们最近为我们的客户解决了这个问题。我们的实施涉及以下组件（但您可以根据您的组织使用不同的工具实现相同的功能）。

• JIRA工作流程 - 谱写的过程（以及拍摄性能指标）管理审批和跟踪历史审核
• JIRA插件 - 触发建立\ \部署通过CI服务器（哈德森\詹金斯）测试。监听：响应状态更新哈德森\詹金斯
• 詹金斯插件 - 与JIRA
• build-pipeline-plugin互动 - 管理詹金斯流程
• 部署脚本 - 詹金斯\ Groovy的

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

干杯，

杰夫

Answer 2

做完这方面的一些研究，我已经花了几天CruiseControl.NET玩耍。由于其可扩展性，它看起来可能会做我想要的一切。在完成所有部署和签署工作的构建结束时，发射另一个插件没有任何障碍。有些要求很复杂，但需要花费很长时间，所以我认为像WWF这样的状态持久性是很有价值的。我将不得不尝试并与同事一起提出。

Answer 3

为此考虑CloudMunch。 CloudMunch提供了一个构建引擎（基于Jenkins），在其之上构建进程工作流程，通过干净的RBAC支持来管理手工工作流，以管理您正在查看的内容。

声明：我在CloudMunch工作。