在为现有生产系统选择开发环境创建方法时应考虑什么？

Question

我们的团队从2-3年前开始就没有开发和测试环境。我们已经决定给予这个(开发和测试环境的创建)更多的优先权。

当前环境

• 一个带有过时软件(OS、编程语言、工具)的生产环境--但是安全补丁是定期安装的。
• 5-6开发人员连接到生产机器以执行开发。
• 操作系统中的单独用户，被认为是实际的生产环境，流程将以自动化的方式运行
• 几乎没有测试套件

新环境选项

我们(至少)有两种方法可供选择，用于设置dev环境：

1. 克隆生产，编写测试，升级所有
   1. 创建一个尽可能接近当前生产环境的dev环境。
   2. 写测试
   3. 升级所有的东西(可能是一个一个地，一个一个地)，看看是否有什么失败(并修复它)。

优点:风险小，风险小:慢点

1. 使用最新版本的所有内容创建新环境，然后迁移代码
   1. 使用最新版本的所有内容(操作系统、编程语言、工具、更多标准实践)创建开发环境。
   2. 开始迁移代码库(虽然代码库有数百个脚本，但可以一次复制2-3个以上的脚本，并确保它们在新环境中运行良好) 。
      1. 修复任何不起作用的东西
      2. 为较新的代码基编写测试

优点:更快(可能)；更快地利用最新特性的能力:可能会花费更多的时间。

Notes

• 有些队员已经在这里呆了2-3年了，而我几个月前就加入了。
• 我倾向于选项2(升级第一，迁移代码)-所以，这两个选项下列出的利弊都是我的偏颇观点的结果
• 另一方面，我的一个队友(我想)赞成第一种选择，因为这看起来有点保守(所以，风险更小)--我可能错了。总的来说，他似乎是个心胸开阔的人。

Answer 1

它可能有助于将其视为两项不同的任务-- (a)创建新的开发测试环境和更改部署实践，以及(b)测试和实现生产环境的OS升级。

我倾向于认为这两项工作本身就是主要的工作。这种重叠只是表面的，因为它们都涉及到配置测试服务器--但是，划分服务器肯定不是主要的斗争。

在(a)中，不需要对现有代码进行重大修改，而是团队未来的开发和部署实践--他们的习惯--必须永久地适应两种不同环境的存在。在部署工具和脚本中也可能需要进行大量的更改(或新的自动化)，以应对代码更改的多个目的地。

同时，在(b)中，生产环境的更改不必涉及测试服务器的永久存在，但它确实涉及验证和可能重新访问大量现有代码，以确保它在新环境中仍然工作。您已经说过，几乎没有现有的测试，因此可能需要对此进行大量的手动检查和重新测试。

我的建议是分开处理这两项任务，无论哪项任务先开始，让结果在一段时间内不立即开始下一项工作。

如果没有，就有一种危险，那就是一次追求太多的目标和改变，陷入混乱，时间表陷入困境，团队因一次规划和执行太多的变化而精神疲惫。