持续集成和预集成
我发布一个部分问题、部分漫无目的的内容，希望它能引发讨论并回答我的问题，如果我诚实的话，这更像是一系列要求。
在我的工作场所，构建工作非常耗费人力。这是因为我们的团队非常小，并且有人怀疑自动化将不可避免地出错，因为我们团队中没有专业知识来正确地做到这一点。我认为这是一个合理但有缺陷的论点。我身边确实有一位中层经理，他似乎很喜欢自动化的概念，并且非常成功地采用了许多小型自动化功能。
我的目标是将一种自动化构建环境与我们的发布系统联系起来，这需要管理人员生成各种文档。这是 TickIT 认证的要求，不用于协商。我想象中要做的是生成一个 (Windows) 工作流程 - 我们为此建立了 IT 基础设施，并且在全公司范围内都很熟悉 - 这会提示经理提供必须提交的文档，以便进行构建和发布。我们不是一家软件公司，我们是一家销售软件的公司，因此这些功能需要面向非技术人员。
总而言之，我们的用例看起来像这样：
- 经理审查任务跟踪器并根据当前状态授权发布
- 工作流程启动，缓存了当前的 SVN 修订版本
- 工作流程要求项目经理提供一些 pdf 文档等，这些文档需要 工作流会
- 在集成管理器（例如 CruiseControl）上启动先前缓存的 SVN 修订版上的构建过程（我将持续集成所做的一切都包含在其中，包括单元测试）
- 完成的安装包会自动安装在各种虚拟机（受支持的操作系统和语言的完整集合），并且可供 QA 使用
- 在 QA 完全签字后，安装包将发布到 Web 上
当然，由于没有任何东西可以正常工作，因此能够“破坏”工作流程并应包括随时手动进行，因为我们不希望发布被一台愚蠢的机器所阻碍，该机器无法完成其工作，而一点常识就可以做到这一点。
有没有人有任何可以被视为此类过程的案例研究，或者对它的简单性或挑战性，甚至它的适当性有任何评论？
I'm posting a part-question, part-rambling in the hope that it will generate discussion as well as answer my question, which is more a series of requirements if I'm honest.
At my workplace, builds are very labour-intensive. This is because our team is very small and there is suspicion that automation will inevitably go wrong because we don't have the expertise in the team to do it properly. This I consider to be a reasonable - but flawed - argument. I do have a middle-manager on my side, who seems to enjoy the concept of automation and has employed numerous small automation features quite successfully.
What I'm aiming to do is tie a sort of automated build environment in with our release system, which requires managers to produce various documentation. This is a requirement of TickIT certification and is not for negotiation. What I am imagining doing is producing a (Windows) Workflow - for which we have IT infrastructure set up and which is familiar company-wide - which prompts the managers for documentation which must be committed in order for a build and release to occur. We are not a software company, we are a company which sells software, so these features need to be pitched at the non-technical.
So in summary, our use case would look something like:
- Manager reviews the task tracker and authorises a release based on current state
- Workflow kicks off, having cached the current SVN revision
- Workflow demands from the project manager a number of pdf documents etc which need to be built into the installation package
- Workflow fires off the build process on the previously cached SVN revision on an integration manager such as CruiseControl (I'm including in this everything that continuous integration does, including unit tests)
- Completed installation packages are automatically installed on various virtual machines (the complete set of supported operating systems and languages) and which are made available to QA
- Upon complete sign-off from QA, installation packages are released to web
Naturally, since nothing ever works properly, the ability to 'break' the workflow and proceed manually at any time should be included, as we don't want release held up by a stupid machine that can't do its job when a bit of common sense would do just as well.
Does anybody have anything which could be considered a case study on this sort of process, or any comments on how straightforward or challenging it might be, or even how appropriate it is?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们最近为我们的一位客户解决了这个问题。我们的实施涉及以下组件（但您可以根据您的组织使用不同的工具实现相同的目的）。
这听起来很复杂，但是很多这些工具都有很棒的 API 可以使用，因此您可以在合理的时间范围内获得稳定的解决方案。
干杯，
杰夫
We solved exactly this problem recently for one of our clients. Our implementation involved the following components (but you can achieve the same with different tools depending on your organisation).
It sounds complex, but a lot of these tools have great APIs to work with, so you can get a stable solution together in a reasonable timeframe.
Cheers,
Geoff
在对此进行了一些研究之后，我最近几天一直在研究 CruiseControl.NET。凭借其可扩展性，它看起来可能可以完成我正在寻找的一切。在构建结束时启动另一个插件来完成所有部署和签核是没有障碍的。有些要求很复杂并且需要不确定的时间，所以我认为像 WWF 这样的某种状态持久性是有价值的。我必须进行实验并与同事们一起提出。
Having done some research on this, I've spent the last few days playing around with CruiseControl.NET. It looks like it can probably do everything I'm looking for, by virtue of its extensibility. There's no obstacle to firing off another plugin at the end of build that does all the deployment and sign-off. Some of the requirements are complicated and take an indeterminate amount of time though, so I think some sort of state persistence like WWF would be valuable. I'll have to experiment and bring it up with my colleagues.
为此请考虑 CloudMunch。 CloudMunch 提供了一个构建引擎（基于 Jenkins），在其之上构建进度工作流程，以在其之上管理手动工作流程，并提供干净的 RBAC 支持来管理您正在查看的内容。
免责声明：我在 CloudMunch 工作。
Consider CloudMunch for this. CloudMunch provides a build engine (based on Jenkins), Build progression workflow on top of it to have manual workflow managed on top of it with a clean RBAC support to manage what you are looking at.
Disclaimer: I work at CloudMunch.