我试图通过构建脚本、夜间构建和持续集成等技术来掌握这个想法，但我看不到它的优势。以此为例：
我们是一个开发应用程序的 4 人团队，没有单元测试。我们还使用 Subversion 进行源代码控制。
使用自定义构建脚本和持续集成之类的东西可以获得哪些好处？您是否“需要”为此进行单元测试？
我还可以提到，我们在本地机器上开发，当代码运行时，我们只需更新生产服务器上的 svn checkout。
【问题讨论】：
标签： testing msbuild continuous-integration
如果您没有continuous integration，您将需要等到有人决定进行集成构建以找出冲突或不一致的提交。集成构建是包含来自所有开发人员的更改的构建。如果每个开发人员都努力更新他们的本地工作副本，那么您可能无需定期集成构建就可以逃脱，但实际上，您为什么不自动化它呢？
测试套件还有助于发现破坏行为但不一定会导致集成构建失败的行为更改。
在新的集成构建上执行smoke test 也是标准做法。
除了检测破坏事物的冲突和更改之外，每晚集成的构建意味着您将始终拥有一个包含每个人迄今为止的工作的最新构建。这是测试和演示目的的福音。
thinking up suitable punishments 对于破坏夜间构建的人来说也有一些乐趣——这意味着他们在没有检查是否正常的情况下提交了东西，所以除了解决构建破坏提交之外，他们应该感到一些痛苦.
【讨论】：
嗯，首先，从已知环境中进行可重复的构建会很有用。如果您需要对特定版本进行小幅更改（例如，即使您现在正在开发 3.2，客户也不愿意从 1.5 版迁移，但您可以在分支上应用 1.5 的补丁），这真的很有帮助轻松构建。
这也意味着，一旦你开始开始编写单元测试，你就会从中获得更多好处。
如果您目前没有任何构建脚本/服务器，您如何构建您发布的内容？只是在一个随机的开发者盒子上？
【讨论】：
那么，您如何确保您的一位同事所做的更改不会破坏任何功能？您是否在每次签到后尝试并测试每一项功能？听起来你可以通过实施单元测试来节省很多时间。
您如何确保两个或多个单独的程序员所做的更改不会干扰下一个在干净机器上进行检查的人将无法构建软件？在计划发布之前，意识到这些问题的好时机很短。
许多这些技术背后的原因是提早失败，这样您就可以查明并更改使您宝贵的软件停止正常工作的任何原因。
现在，您不需要持续集成的单元测试，但它们肯定是您构建过程的重大改进，您绝对应该考虑阅读并使用它们！
【讨论】：
使用 CruiseControl 和 CCTray 之类的东西会给您信心，您知道当那个小图标变绿时，您可以获得最新的代码，并且很可能与您的本地副本一起使用。
要从中获得最佳效果，您需要养成良好的习惯，在提交之前始终保持最新等。它不会停止冲突，甚至是损坏的构建，但它会让您充满信心地推进您的开发有一个工作版本的软件。
使用自定义构建脚本再次让您充满信心，因为您可以完成构建，然后运行单元测试、代码覆盖率、fxcop。这一切都增加了代码主体的质量。
与往常一样，需要时间和精力成本，但您很快就会在需要多少质量以一致地交付软件与您想要进行多少测试和代码分析之间取得平衡。
【讨论】：
拥有专用构建机器（将 CI、单元测试甚至自动化构建放在一边）的主要优势是确保您拥有一个干净、可预测和可重现的构建环境。
仅此一项就应该会导致更稳定的产品发布。它可以帮助您在部署/发布后更早地发现解决方案和代码库的问题。一个常见的例子可能是在开发人员的机器上经过 GAC 处理但在部署的产品中丢失的组件。
自动化构建非常有用，因为它们消除了人为因素 - 即它们每次都重复相同的步骤（例如，它们不太容易忘记构建步骤） - 这使您具有可预测性。如果您使用相同的源运行相同的构建脚本，您应该得到相同的输出。这对于正确的发布管理至关重要。
当您开发构建环境时，可以对其进行扩展，以便为开发团队提供更多支持 - 特别是在团队开始壮大时。其余的可以讨论 - 如果您（或您的团队）可以看到降低项目风险或工作量的价值，则可以实施。
持续集成 (CI) 基本上可以让您更早知道是否与项目的源代码/解决方案有任何冲突 - 即，在团队其他成员从源代码管理中刷新源代码时，他们会在收到损坏的代码库之前知道。
这里的主要优势是更快地解决损坏的代码库 - 通常当它在人们的脑海中仍然新鲜时（因为理论上，他们只是将更改提交到源代码控制存储库）。但是，人们确实需要密切关注它..
【讨论】：
简单地说，我们使用它来确保如果有人将代码提交到集成分支/发布分支，并且没有经过适当的测试，我们会在 10 分钟内而不是 10 天内发现。
我们不使用它来测试，我们使用它来备份我们的测试过程。
【讨论】：