问题标签 [continuous-integration]

我准备第一次使用持续集成。我将使用 Nant 进行自动化构建和测试任务，并尝试找到合适的 CI 工具来轮询存储库并执行 Nant 脚本。

到目前为止，我已经大致研究了以下内容：

• 哈德逊
• 巡航控制
• 德拉科

到目前为止，我的感觉是，由于大部分工作将由 Nant 完成，Draco 会很好，因为它应该很容易安装/设置。另一方面，Cruise Control 和 Hudson 可能会提供更好的报告选项。

将 Nant 用于构建和测试任务时，执行持续集成的最佳方式是什么？

我想从 teamcity 中提取工件。

我一直在尝试使用 c# 和 HtmlAgilityPack 来访问该网站并找到最新版本及其工件。我目前卡在登录状态，我想我只需要发送会话 Cookie 即可。

我是否朝着正确的方向前进，有其他人尝试过吗？

我意识到使用构建脚本推出文件很容易，但我想尽量减少对 Ant、NAnt 文件的更改，因为我正在考虑将其扩展到 100 个应用程序。

编辑：这个问题看起来很有前景Getting HTML from a page behind a login

编辑：现在可以了，我只需要编写一些代码来解析它

根据实际经验，我想问一下您认为哪种自动化构建环境更好。我打算做一些.Net 和一些Java 开发，所以我想要一个支持这两个平台的工具。

我一直在阅读并发现了用于 stackoverflow 开发的CruiseControl.NET和TeamCity，它支持在不同的操作系统平台上基于不同的编程语言构建代理。那么，如果您在这两个方面都有一些实践经验，您更喜欢哪一个，为什么？

目前，我最感兴趣的是该工具的易用性和管理性，更不用说 CC 是开源的，而且当你有很多项目要运行时，TC 在某些时候会受到许可（因为，我少量项目需要它）。

此外，如果有其他工具可以满足上述要求，并且您认为值得推荐 - 请随时将其包含在讨论中。

我的公司下周开始一个新项目。我们计划使用 eclipse rcp 开发应用程序。构建过程应该是完全自动化的，所以我们准备建立一个持续集成环境（例如 Continuum）。对于构建自动化部分，我打算使用 maven2，因为我想使用它的依赖管理。

我曾将 maven2 用于一个小型的老式 java 项目，但从未设置 maven 以将其与 eclipse rcp 一起使用。

最好的方法是什么？基本概念？常见的陷阱？那里有教程或书籍吗？我发现的教程和信息似乎过时或不完整。

PS：主项目将分为子项目（插件）。但我认为这对于 eclipse rcp 项目来说是典型的。

在过去的两年里，我曾在两个使用敏捷/Scrum 方法的不同团队中工作，两个团队都渴望改进他们处理软件开发的方式。在第一个团队中，我们可以很容易地说服我们的产品负责人花时间进行内部工作，例如改进构建系统、设置更好的集成测试、制定更好的发布策略等。现在 PO 也愿意给我们时间，但是他更加推后，这是合理的，因为他也必须完成他的事情。

无论如何，我现在的问题是，其他团队如何处理这个问题？您是否创建了一个改进故事并在计划期间将其放在桌面上，或者您是否为此类事情保留“桶”时间？根据您的经验，说服产品负责人花时间进行改进有多难？毕竟，所有这些改进都会使团队受益，但不会直接或立即使产品所有者/企业受益。

在使用 Hudson 与之前的项目进行持续集成之后，我想为我现在正在处理的 iPhone 项目设置一个持续集成服务器。在做了一些研究之后，似乎没有任何专门为 Xcode 设计的 CI 引擎，但是有人成功地使用了 Cruise Control 和 xcodebuild CLI 工具。这里有人试过吗？是否有任何与 Xcode 项目配合良好的 CI 引擎？

我可能会尝试巡航控制。我会用我的发现发布答案。

我可以想到很多使用它的充分理由；但是，它有什么缺点呢？

（除了购买另一台服务器）

使用每日构建而不是它有什么好处？

维护代码时要遵循的最佳实践和经验法则是什么？在开发分支中只有生产就绪代码是一种好习惯，还是应该在开发分支中提供未经测试的最新代码？

你们如何维护开发代码和生产代码？

编辑 - 补充问题 - 您的开发团队是否遵循“尽可能提交并且经常即使代码包含次要错误或不完整”协议或“提交-将代码提交到开发分支时只有完美代码”协议？

我一直在探索在一些 Nant 构建脚本中运行集成测试的不同策略。通常，许多不同的脚本链接在一个具有单独目标的整体构建中：staging（构建一个暂存版本，如 build）、build（只是构建东西）、集成（构建东西并运行集成测试）。这工作得相当好，构建目标需要大约三分之一的时间作为集成目标运行，而且时间不长，所以我发现自己并不不愿意经常运行它。

另一方面，集成目标需要足够长的时间，以至于我不想经常这样做——最好是在我准备好进行部署之前。这看起来是一个合理的策略吗？IOW，我做得对吗？

计划是最终将此项目转移到持续集成。我是整个持续集成的新手，但我想我理解“打破构建”的概念，所以我想知道为了充分利用它，有哪些好的实践可以学习？

任何有关此主题的良好阅读资源也将不胜感激。谢谢！

好的，所以我欣然承认在持续集成方面我是新手。

话虽如此，我正在尝试设置一个 CC.NET 环境来教育自己，但我无法找到设置自动构建部分所需的信息。

据我了解，在 C# 中，由 VS 2005 和转发生成的 .csproj 文件是有效的 MSBuild 文件。也就是说，我已经能够使用 .csproj 文件将 MSBuild 任务集成到 CC.NET 中，但是我对此有一些问题：

1. 这里发生了很多事情，我不确定我是否真的需要在自动构建环境中。
2. 我没有创建这个文件。我不明白，这让我害怕。（巧合编程）
3. 大多数正在发生的事情似乎都是通过抽象的$(MSBuildToolsPath)\Microsoft.CSharp.targets
4. 作为 1、2 和 3 的结果，修改文件以包含 MbUnit 之类的内容似乎很复杂，而且比它需要的更困难。我唯一真正的选择是将它包含在该AfterBuild部分中，这对我来说似乎有点像 hack。

所以，有几个问题要问 CC.NET 人员、MSBuild 人员和 MbUnit 人员。

1. 在使用 MSBuild 时，是否建议使用 VS 生成的 .csproj 文件作为构建文件？还是我应该创建自己的？
2. MbUnit 测试应该是 MSBuild 文件还是 CC.NET 文件的一部分？我的研究似乎表明它们属于 MSBuild 文件。如果是这种情况，除了 .csproj 文件之外，我是否要创建一个新的 MSBuild .proj 文件并将其签入 CVS？还是 MbUnit 任务成为我的 .csproj 文件的一部分？
3. 与问题 2 类似。如果我将 MbUnit 测试添加到 MSBuild 文件并最终使用 .csproj 文件，那么Target Name="AfterBuild"真的是添加该信息的部分吗？不应该有一个Target Name="Test"部分吗？使用 VS 生成的 .csproj 文件似乎阻止了第二种选择。

我知道那里有很多东西，但是我在网上找到的大部分内容都假定我对这些我没有的主题有一定程度的熟悉——除非我弄错了，否则这些东西的学习曲线是根本不是曲线，而是阶跃函数。:)

编辑 1：我更新了文本，使其更加简洁，并解决了我在答案中遇到的一些挥之不去的问题。