背景
在我们开发实际产品的过程中，最普遍的一个需求就是如何快速的构建属于自己的测试，开发环境。多开发，多测试环境的方案纷繁多样，如何选择一条适合自身产品，自身团队的技术栈十分重要。
历史
我们所要解决的问题本质其实就是前些年大火的 DevOps 概念中的一个层面。DevOps 起源历史悠久，最早可追溯到 2007年的比利时独立咨询师 Patrick Debois，他当年从事的政府项目时，需要频繁和开发团队，运维团队打交道，遇到了一些列的问题促使其思考如何让协助更加敏捷，工作高效。
2009 年 Flickr 公司的 John Allspaw 和 Paul Hammond 发表的一场关于 ““10 Deploys per Day: Dev and Ops Cooperation at Flickr” 演讲引发了对于研发和运维目标一致相互协作的新观点，这场演讲也进而推动了Debois 举办了一个名为 DevOpsDays的大会，这场大会至此让 DevOps 正式走上历史舞台。
追本溯源，我们知道前人们在 DevOps 演进中，引入了敏捷，自动化，精益，目标协作等形而上学方法论的东西，无非是为了解决和满足系统随时上线，协作整体效率提升的痛点，既然大的痛点我们各有体会，那么说说一下我们自身业务需要解决的痛点主要是什么。
痛点
多环境部署的几个刚性需求无外乎如下几个：
- 自助化接入，接入流程简单
- CI，CD 流水线支持，基本的权限管理
- 环境尽量隔离，相互开发测试互不影响
- 随时可以测试验证新功能，编译，部署效率高
关于 CI/CD 和 DevOps 的区别和联系，可以参考 https://www.quora.com/What-is-CI-CD-in-DevOps 这篇问答中的几张图片来体会一下。
业界方案
知道了痛点，问题就变得越发清晰了，就如同知道了为什么，才能更好地想怎么做。在实际实施前，我们先看看业界目前的玩法都有什么，有什么值得我们学习和借鉴的。
CI/CD 开源: Jenkins, Jenkins X， Gitlab CI/CD，Spinnaker， Travis CI，Github Actions 等
CI/CD 云厂商和公司：
CircleCI，Cloud bees CodeShip, Drone
AWS CodePipeline，Google Cloud Build，Azure Pipelines ，腾讯云 Coding DevOps
综合 CI/CD 的工具的特点我们可以发现几个特点：
- 基于云的 CI/CD 方案趋势化
- 私有化的 CI/CD 方案支持
- 面向云原生系统的 CI/CD 支持
公司方案
公司的 DevOps 类似织云等工具，在内部有着广泛的用户，承载了很多流程上的一些可以快速利用的能力，借助这些能力实现开发，测试的快速验证，快速部署，对于整体的研发效率提升都有着很大的帮助。
考虑环境中对现有的共有域名的重用，所以设计依靠路由转发，这种方案本身也支持前后端使用各自的代码分支进行发布测试，选取了一种如下的 Devops 自助开发环境：
选取架构
自助式研发测试环境上面的自助方案也有一些缺点：非完全独立环境，依赖的一些第三方回调接口没有完全隔离。 在架构实施过程中，我们也遇到了其他的问题，对于这些问题给出了一些相应的处理方式：
- 镜像是否包含应用依赖的 agent，比如名字解析服务等基础的 agent
目前有公有镜像，自己维护私有镜像（打包 agent 方式），DameonSet（独占集群场景)
- TKE 支持 CLS 日志方式和传统的 VM 上 loglistener agent 结果差异
如果应用之前集成过 CLS API 调用，可能需要代码适配调整
- 日志存储 volume 对于 CBS 支持是否灵活
暂时采用类似 hostPath 方式
- TKE 和 VM 跨地域配置下的通信延迟问题
程序优化，和集群调整部署，远程一些依赖进行容器化
- 对外开通 80， 443， 其他端口暂时无法直接访问
VPC 内网访问内网 Nginx 转发
遗留问题
- 共享数据的冲突
多个独立环境，共用一套 db 配置，可能引起不同进程更新共享数据的问题
- 底层回调依赖问题
目前一些依赖的第三方回调都是配置的线上回调，第三方没有很好的机制支持动态注入其他信息，无法确切知道是
哪个开发环境调试触发，因此很难转发到对应的 service IP
- 集群日志的隔离
因为集群日志的接入是独立的，所以需要各自的日志主题配置
- 其他共享数据问题
共享的分布式 k-v 数据库，MQ 配置等
解决方案
方案1 - 减少数据依赖，独立数据方式
- 优点： 隔离性，安全性好
- 缺点：成本大 （硬件，或者软件方案）
如果不考虑硬件共享问题，随着泛化上云的普及，这种方式应该是更偏向完美
方案2 - 优先主要程序隔离（2，8 原则），减少不重要进程依赖
- 优点：关注主要精力类似主应用服务器的隔离开发
- 缺点： 其他进程共享方式，如果单独开发调试支持有难度
方案 3 - 减少底层依赖，增加 Mock 支持
如果底层可以根据 SDK 开发，确认是否有相应的测试模拟工具支撑
- 优点： 可以任意模拟支持底层依赖
- 缺点： 引入新的协议变更，需要同步修改模拟工具，增加了一定程度的维护成本
方案 4 - 增加特性开关支持
- 优点：特性开关方式，可以减少其他开发者因为共享数据导致的问题
- 缺点：大部分修改，没有独立的修改部分，特性开关不太现实
短期看，方案 2 成本小，长期看，方案3 ，方案 4 较灵活，方案1 偏向完美，但是成本稍高
参考
1. https://en.wikipedia.org/wiki/DevOps
2. https://devops.com/the-origins-of-devops-whats-in-a-name/
3. https://insights.thoughtworks.cn/instantiate-the-principles-of-devops/
4. https://www.quora.com/What-is-CI-CD-in-DevOps
