针对共享开发环境的争论

Question

因此，我现在的雇主经常头疼的是，我们（开发者）都有共同的发展'测试'环境。目前的流程如下：

1. Dev在项目分支的工作副本上处理一项功能
2. 当他们确信它有效时，请测试共享开发环境中的更改
3. 检查

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

1. 由于项目之间发生了很多重叠，因此经常存在资源争用
2. 由于更改都是由开发人员手动输出的，因此环境可能处于非常不一致的状态（即某些服务已损坏，其他服务更新或比预期更旧）
3. 当开发人员测试某项服务时，他们通常可以多次启动和停止该服务 - 当您的工作依赖于该服务时，您会坐下来等待他们解决问题

我正试图通过他们自己的开发环境提出一个论点来提供每个项目（试图为每个开发人员射击月球）。我正在寻找能够对我的经理有意义的论点（半技术，主要是业务，底线）。以下是我目前的论点：

• 针对已知版本的依赖项提供的功能 - 使部署更容易上线
• 资源竞争减少，因为项目团队足够小（4-5个开发人员），团队内部沟通足以分配资源
• 更多的开发测试应该能够捕获更多需要在QA中找到的缺陷
• 应该驱逐仍旧硬编码的配置详细信息

这些都很好，但我认为我还没打过本垒打。如果你想提出相反的论点并为我提供一些方法来使我现在的环境变得更好，我对此持开放态度（尽管持怀疑态度）。

感谢。

Answer 1

我在这里看到的主要问题是，你无法通过让人们进入共享开发环境来创建一致的，可重现的版本。

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

通过这种方式，您将准确了解已发布到QA环境中的版本，并且您将能够始终如一地复制该版本并将其应用于其他环境。

这也非常适合自动构建过程，这意味着构建每次都以完全相同的方式运行，因此您不依赖于手动步骤来确保构建发生，这将减少人们“打破构建”的效率当他们忘记手动部署时。