使用构建脚本和持续集成的原因是什么?

ale*_*exn 4 testing msbuild continuous-integration

我试图通过构建脚本,夜间构建和持续集成等技术来掌握这个想法,但我没有看到优势.以此为例:

我们是一个开发应用程序的4人团队,没有单元测试.我们还使用Subversion进行源代码控制.

使用自定义构建脚本和持续集成等方面可以获得哪些好处?您是否"需要"单元测试?

我还可以提一下,我们在本地机器上开发,当代码工作时,我们只需更新生产服务器上的svn checkout.

Ed *_*ess 7

如果您没有持续集成,则需要等到某人决定进行集成构建以找出冲突或不一致的提交.集成构建是包含来自所有开发人员的更改的构建.如果每个开发人员都在努力更新他们的本地工作副本,那么你可以在没有常规集成构建的情况下逃脱,但实际上,为什么不自动化呢?

测试套件还可以帮助发现破坏事物但不一定导致集成构建失败的行为的更改.

在新的集成构建上执行烟雾测试也是标准做法.

除了检测冲突和破坏事物的变化之外,夜间集成构建意味着您将始终拥有一个包含迄今为止每个人工作的最新构建.这是测试和演示目的的福音.

对于那些打破夜间构建的人来说,考虑适当的惩罚也有一些乐趣- 这意味着他们在没有检查它的情况下犯了东西,所以他们除了解决构建破坏的提交之外还应该感到一些痛苦.

  • 或者有人做了更新并且遇到了破坏的构建. (2认同)
  • 我总是宁愿推广良好的做法,而不是惩罚邋work的工作.这取决于地方的文化以及打破建筑的个人. (2认同)