Continuous integration 在镜像但独立的生产环境中开发时遇到问题

我对“开发环境应该尽可能接近生产环境”有一些问题

（生产机器的操作系统是Linux。）

我对开发步骤的理解（大致）：

• 编码、编译、测试/运行、重复

“通常”我会在自己的机器上检查这些代码，然后将代码推送到CI进行测试，并可能进行部署。CI将负责在与生产环境匹配的环境中运行测试，这样，如果测试通过，则可以安全地假设代码也在生产环境中工作

大环境问题 ☑ 数据库-某种类型。
☑ 作业处理池-用于某些长期运行的后台任务。
☑ 用户帐户管理-也可由其他系统使用。
☑ 集中式日志记录-用于健全性。
☑ 转发代理-将单个http可访问服务绑定在同一url但不同路径下。
☐ 以及可能的其他服务或服务集合

解决方案

• 都在我自己的机器上？绝对不行
• 都在虚拟机上？也许吧，但是如果这个设置应该镜像prod.env.和prod.env.，那么安全性是明智的。就像这样，嗯。。如果发生违约，这可能不是一个好主意
• 按责任划分并在多个虚拟机上设置它们？谁来管理这些机器？我认为有可能做得比这更好
• 使用容器，比如Docker，或者自己将类似的东西拼凑在一起？听起来不错：（可能：）非常快的迭代周期，关注点的分离，分离带来的一些安全性，以及容易的再现性

为了简单起见，假设我们选择的容器化工具是Docker，我们不打算自己使用libvirt/lxc工具/直接内核调用构建一个容器化工具

Docker就是这样，可能是CoreOS或ProjectAtomic。因此，现在有了一个应用程序（或多个应用程序）的容器，它与系统的其余部分分离，可以在任何地方以几乎相同的方式启动

• 解决方案1：生产环境美观大方
• 问题1：这不是开发环境

发展环境 无论如何选择不必将生产环境喷洒到我自己的机器中，问题仍然是一样的：

即使生产环境设置正确，我也必须在某个地方运行编译和测试，然后才能部署（可以是CI的另一轮测试或其他测试）

我如何解决这个问题

解决这一问题的正确方法真的是在我自己的机器上编写代码，让代码在虚拟化镜像生产环境中同步/直接可见，从而自动化测试的运行吗

如果我不想运行所有的测试，而只想运行我正在编写的部分，会发生什么？我是否每次都编辑自动编译过程？远程调试又如何呢？因为必须协调多个系统才能以正确的方式运行，并且调试必须在两者之间附加到其中一个程序。更不用说“代码，测试”循环的速度了，这会非常慢

这听起来很像CI，但多个开发人员不能都使用同一个CI并对其进行修改，因此他们可能必须在自己的机器上进行此设置

---

我还认为，开发人员可以各自使用一个完全虚拟化的操作系统，该操作系统包含所有开发工具，并与生产环境进行镜像，但这将迫使资深用户采用虚拟开发环境的工具，这听起来不是个好主意。

不完全清楚你在问什么问题。您似乎正在概述该规则的例外情况。我的评论是注意到声明中“尽可能”的部分。您的开发越像产品，您的测试在发布之前发现问题的可能性就越大。这并不容易，特别是对于一个遗留系统，但我会犹豫说这是不可能的。在理想情况下，开发人员和产品之间唯一的区别就是应用程序的数据。