问题描述
正在开发一个相当大规模的项目（超过250个Docker容器），该项目对多个API和前端应用程序有复杂的依赖关系。暂时使用Kubernetes运行在staging和production环境中。用户的团队由大约50名开发人员组成，他们都在公司的MacBook上运行macOS。团队分为不同的小组，每个小组负责项目的特定部分。有些人是前端开发人员，有些人是后端开发人员。目前，他们都在本地的笔记本电脑上使用本地安装的依赖项或通过Docker容器（mongoDb、PHP、RabbitMQ等）进行开发，但他们只能安装当前正在开发的项目的特定部分，因为似乎无法在每个开发人员的笔记本电脑上同时运行整个项目，但这种方法非常笨拙，并且在不同的开发人员机器上可能会有所不同。用户喜欢使用docker-compose的整个项目在本地运行的想法，但根据他的经验，一旦有几个docker卷在运行，MacBook就会变得非常慢。目前，切换到Linux笔记本不是一个选择。
用户想知道其他大型公司是如何解决这个问题的。他希望能够获得与生产系统类似的体验，可能在本地运行类似Minikube的东西，但他不认为性能会更好，而且对新开发人员来说会增加很多复杂性。他们还考虑在Linux虚拟机上运行开发环境，但这可能很快变得昂贵。
大公司/项目中的人们是如何处理这个问题的？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在面对复杂的情况时，重要的是知道如何思考，而不是如何做。对于这个问题，一个指导原则可能是来自12factor应用的“开发/生产一致性”概念。它的原则是尽量使开发、staging和production环境保持一致。
如果各个组件的开发团队遵循独立的发布周期（如果应用程序是由微服务组成的，那么应该是这样），那么在开发过程中，有一个共享的集成环境是有意义的。这个环境可以远程托管，并为所有开发人员提供一个统一的环境。
当然，这意味着你需要访问这个共享环境，因此需要网络连接，这样你就会失去一些离线功能。然而，似乎唯一的保持离线开发能力的方法是升级每个成员的硬件，所以我猜你不管怎样都会被迫在连接到网络的情况下进行开发。如果你要访问网络，那么你也可以访问共享的集成环境。
当然，确保这个环境保持最新和正确是有难度的。这就是持续交付的实践所在。如果有4个团队分别负责应用程序的4个组件，那么对这4个组件的更改应该被适当地版本化，并持续交付到共享环境中。
方案2
另一种解决方案是通过CI/CD来动态地创建开发环境。你可以考虑使用CI/CD来临时创建开发环境。
另一个更直接的解决方案是使用VS Code的SSH插件。由于你已经在使用Docker，你可以在远程开发服务器上构建EC2服务器并远程运行容器，然后开发人员通过SSH登录到EC2服务器。
请注意，在远程开发服务器上，你可以安装Docker插件（或任何VS Code插件）来改善开发体验。