反对共享开发环境的论据

Question

因此，我们(开发人员)都有一个共同的开发‘测试’环境，这让我现在的雇主头疼不已。目前的程序如下：

1. Dev在他们的项目分支
2. 的工作副本上工作一段功能，当他们确信它能工作时，在

中测试共享开发

• it中的更改。

因此，这里出现了几个明显的问题：

由于项目之间存在大量的重叠，因此经常会发生resources

• Since的争用--更改都是由开发人员手动完成的，环境可能处于非常不一致的状态(例如，有些服务被破坏，另一些服务可能较expected)

• When更新或旧一些--开发人员正在测试服务，它们通常可以启动和停止服务几次-当您的工作依赖于该服务时，您就会坐着摆弄拇指，等待它们解决

问题。

我正试图提出一个论点，为每个项目(尝试每一个开发都是为月球拍摄)提供自己的开发环境。我正在寻找我能提出什么样的论点，这对我的经理来说是有意义的(半技术性的，主要是商业上的，注重底线的)。以下是我目前的论点：

resources

• More

• 针对已知版本的依赖关系提供了功能--使部署更加容易，减少了对资源的竞争，因为项目团队规模足够小(4-5个开发人员)，团队内部的通信足以分配

• 开发测试，因此，如果要排除仍然是硬编码的

，那么需要在QA

• 中找到更多的缺陷。

这些都不错，但我想我还没有打出本垒打。如果你想提出相反的论点，并为我提供一些方法，使我目前的环境更好的地方，我是开放的(尽管怀疑)。

谢谢。

Answer 1

我在这里看到的主要问题是，您无法通过让用户进入共享的dev环境来创建一致的、可复制的版本。

一般来说，您将运行本地开发环境并将更改提交到中央代码存储库中。然后，您将从该中央存储库构建您的版本。

这样，您将确切地知道您已经发布到QA环境中的版本，并且您将能够始终如一地复制该版本并将其应用于其他环境。

这也很好地帮助了自动构建过程，这意味着每次构建的方式完全相同，这样您就不会依赖手动步骤来确保生成的发生，这将减少人们在忘记手动部署时“破坏构建”的不确定性。