自从我 5 个月前加入公司以来，我一直在推动持续集成，但是在看到我们工作的应用程序类型后，我开始认为为每个项目都设置工作可能不值得持续集成。
如果您在开发部门工作，平均项目需要 2-3 周，并且一旦部署，您很少需要担心，那么持续集成是否值得设置它的麻烦？
Omar Kooheji
问问题
2615 次
7 回答
12
可能取决于你的过程。如果您有涵盖代码的单元测试，那么持续集成是值得的。我假设你们都在一个工作模块上工作，因为这些项目需要 2-3 周。
我不认为人们会为他们的每一个提交运行每一个测试，并且持续集成在这里有很大帮助。
另一个原因是您的项目是否高度模块化。我曾在有很多模块的系统中工作过，开发人员在提交之前不会对整个网站进行功能测试。事情甚至可能无法正确编译，因为开发人员没有检查完整的代码，甚至无法构建其他模块。
无论如何，我建议持续集成。使用像 Hudson 和 Cruisecontrol 这样的设置，它不需要很多时间来设置并很快收回成本。
于 2009-01-22T15:27:34.783 回答
3
就个人而言，我认为 CI 及其鼓励的各种流程总是有用的。一旦你自己设置了服务器，获得 CI 设置就相当简单了。你基本上只是从一个项目中复制一个配置文件，编辑它，然后创建一个新项目。由于“设置每个项目的努力”，我不会使用 CI。
于 2009-01-22T15:34:25.817 回答
2
持续集成不仅仅是一个工具的问题，也是一套流程（定期提交，有一个版本控制系统......）。
关于 IC 软件，您可以在不到 10 分钟的时间内安装、配置并开始使用Hudson ！那么，为什么你会不使用任何 IC 系统呢？
于 2009-01-22T15:28:33.423 回答
1
这实际上取决于您可以多快地设置自动构建，然后将其连接到 CI 服务器。
。网
我已经看到我们使用 UppercuT 在几分钟内从没有自动构建到项目的自动化构建。我们使用它和 CruiseControl.NET（在配置中，我们为每个项目添加一行 b/c 我们利用预处理器）。
http://code.google.com/p/uppercut/
这里有一些很好的解释：Uppercut
于 2009-05-16T19:23:42.347 回答
0
如果您的许多应用程序共享任何常见的组件或模块，CI 和测试可能会帮助您发现某些问题。如果它们真的都是扔掉的、自包含的脚本，那么你可能不需要 CI，但这是一个艰难的决定。
于 2009-01-22T15:35:29.057 回答
0
正如其他人指出的那样，一旦设置了 CI，然后添加一个新项目就很简单了，所以我会说去吧。您将看到的一个好处是，如果您的任何项目确实发生了变化，您已经有了 CI，并且希望您的单元测试准备好进行，这样您就不会得到任何令人讨厌的惊喜！
于 2009-01-22T15:35:51.100 回答
0
持续集成不仅确保工作正常，还允许您记录和测试发布过程，就像新开发人员所做的那样。
这确保了客户得到的是经过测试的东西，而不是开发人员从他的硬盘中随便扔掉的东西。
这对于维护目的可能非常重要。
于 2009-01-26T13:36:51.003 回答