问题标签 [build-automation]

我们的团队正在设置夜间和持续集成构建。我们拥有 Team Foundation Server，可以使用 Team Foundation Build。我更熟悉 CC.Net 并以这种方式精益求精，但管理层看到了花在 TFS 上的所有资金并希望使用它。

我更喜欢 CC.Net 的一些地方是通知的灵活性以及实现自定义脚本的简易性。

如果您对这两种产品都有经验，您更喜欢哪一种，为什么？

我在 Windows 上使用 CVS（带有 WinCVS 前端），并且希望在构建失败时将上次签入的详细信息添加到来自我们的自动构建过程的电子邮件中，以便更容易修复。

我需要知道已更改的文件、更改它们的用户以及评论。

我一直在尝试制定命令行选项，但似乎从来没有得到准确的结果（要么得到太多的结果，而不是仅仅从一次签入，或者两周前的一些随机签入的详细信息）

我正在尝试为我当前的项目创建一个构建脚本，其中包括一个 Excel 插件。加载项包含一个带有文件 modGlobal 和变量 version_Number 的 VBProject。每次构建都需要更改此数字。具体步骤：

1. 使用 Excel 打开 XLA 文档。
2. 切换到 VBEditor 模式。(Alt+F11)
3. 打开 VBProject，输入密码。
4. 打开 modGlobal 文件。
5. 将变量的默认值更改为当前日期。
6. 关闭并保存项目。

我不知道如何自动化这个过程。我能想到的最好的方法是一个 excel 宏或 Auto-IT 脚本。我也可以编写一个自定义的 MSBuild 任务，但这可能会变得……很棘手。还有其他人有其他建议吗？

标题应该说明一切，然后我可以在 Joel 测试中再巩固 2 个刻度。

我已经使用 makefile 和 python 脚本实现了构建自动化，并且我了解基础知识和选项。

但是，作为阅读博客的新人，我如何才能让我的团队相信它的内在功效呢？

假设您正在开发需要在多个主机（例如 Linux 和 Windows）上编译和运行的代码，鉴于以下情况，您将如何以最有效的方式执行此操作：

• 您可以完全访问要编译的每个主机的硬件（在我的情况下，一台 Linux 主机和一台站在我办公桌上的 Windows 主机）
• 在网络驱动器上构建太昂贵了
• 不需要提交到中央存储库——假设有一个 CI 引擎会在签入任何内容后立即尝试构建

“高效”意味着使编译-编辑-运行周期尽可能短和简单。

我们正在尝试使用 TestComplete 将测试集成到我们的日常构建中，到目前为止，我们有一台专用于测试的机器，我们的构建脚本将 TestComplete 测试所需的一切（应用程序、数据库、测试脚本项目和源文件等）复制到这台机器上.

基本上我们可以手动打开 TestComplete 项目并运行测试。

现在我们想要自动化这个过程，那么你是怎么做的呢？或者您认为实现这种自动化的最简单和最好的方法是什么？

简而言之，我们希望在每次构建后自动化打开 TestComplete 的过程，运行所有测试并发送包含测试结果的电子邮件。

任何人都可以分享一些这方面的经验吗？

谢谢。

您使用哪些工具进行自动构建/自动部署？为什么？

你推荐什么工具？

我正在设置一个 Greenfield (yeeea!) Web 应用程序，刚才我想知道其他人如何首先设置他们的项目以进行自动化/CI 构建？

我一般遵循这个：

1. 创建具有基本布局（主干、分支、库等）的 SVN 存储库
2. 创建基本解决方案结构（核心、用户界面、测试）
3. 创建一个失败的基本测试
4. 复制 NAnt 脚本，更新和调整，确保失败的测试在本地中断构建
5. 犯罪
6. 在 CI 服务器 (TeamCity) 上设置默认调试构建，确保构建失败
7. 修复文本
8. 提交 9 确保构建通过 CI
9. 完毕....

我想自动化设置新 PC 的过程，这将包括下载和安装最新的 Windows 和 Office 更新；从网络共享安装软件（某些软件需要重新启动，因此脚本需要能够登录并继续）将 PC 添加到域并设置本地用户帐户。

这可能吗？实现这一目标的最佳脚本语言是什么？

什么构成了一个好的 CI 构建过程？

我们使用 CI，但是当您依赖于应该部署的多个服务并且其他应用程序也可能依赖于这些服务时，部署到生产甚至是一个现实的 CI 目标。

当一个好的 CI 构建过程自动化到 QA 并从那里手动时，它是否足够好？