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