build - 开发人员应该在沙盒中工作吗？

Question

如果开发人员在签入源代码控制之前在其开发环境中执行单元测试，是否应该共享该环境（包括测试失败）？

所有构建都应该公开吗？

Answer 1

我认为将开发人员构建公开是不切实际的。您不希望遇到的每个构建失败（单元测试失败）都打扰您的团队成员。

您总是在为某些问题创建解决方案的过程中，并且很可能第一次就无法正确解决，因此单元测试失败会经常发生。特别是如果您采用测试驱动的方法来开发代码：首先编写单元测试并实现功能，这样它就不会再失败了。

Answer 2

我认为在沙盒中工作是个好主意。它救了我几次。我通常会使用一些不同的虚拟机来进行开发，如果我把它搞砸了，我不必等待我的机器被重建。

我认为不应该公开来自简单开发人员构建的所有测试结果。我并不担心通过公开他们所有的失败来伤害某人的感情，但我担心他们提供的信息没有用。

研究某种类型的系统会很有趣，在这种系统中，开发人员在签入时需要提交通过的测试结果，但我认为即使这样也会推动事情。它可能会产生损害生产力的不利影响。开发人员已经有足够多的非编码工作要做了。

Answer 3

孩子们应该在沙盒中玩耍；），软件开发人员应该在他们自己的 PC 上玩耍，并在他们觉得代码达到一定质量水平时提交他们的代码。当每个人都定期提交和更新经过测试的小段代码时，我的经验是不会出现严重的问题，只有建设性的反馈，有时有人会大喊大叫。最后将软件发布给公众/客户是另一回事。这需要大量测试、编写发布说明、更新手册、营销等。

Answer 4

是的，如果可能，开发人员应该在沙箱中工作。默认情况下，任何构建都不应该全部公开。TDD 将导致测试和代码的多次失败和改进。公开共享构建可能很麻烦，但如果其他开发人员足够关心去看看，他们当然应该能够看到某人在做什么。当被要求这样做时，它们应该被公开。如果您要求证明他们测试了某些东西，那么在他们签入代码后运行他们的单元测试应该足以证明。

为开发人员提供环境、工具和自由测试更改的自由将提高软件的稳定性和质量。测试理论和故障排除通常需要小的增量构建。如果沙箱价格昂贵，则应要求他们预留时间来使用它。为每个开发人员提供一个私有沙箱可能会导致他们的代码长时间分支。你问这个的动机是什么？如果开发人员试图隐藏某些东西，那么就要找到该问题的根本原因。如果您想控制成本，请考虑预订模式。

Answer 5

你从中看到了什么好处？特别是，这意味着每个人都会收到有关每个开发人员每次 picayune 测试失败的电子邮件。

这只会分散大家的注意力。

避免仅仅因为有可能就去做某事的诱惑；让您的需求驱动您的流程。不要仅仅因为可以就创建新流程。