从DevOps中挖掘docker的价值

简介

【唯实践】容器环境应用一键拉起实践 （值得再读好几遍）

我们的PaaS容器部署环境目前分为功能测试环境，联调测试环境和回归测试环境三大类，其中功能测试环境包含了多个有业务开发灵活实时创建的隔离环境，用于功能验证使用，而联调和回归环境部署了所有可以上云的应用，用于各类应用的集成大联调以及上线前的回归测试验证。各个环境间 通过Kubernetes的namespace进行隔离 ，同时在微服务应用级别也通过我们微服务基础设施提供的分区功能实现 逻辑上的配置和路由隔离 ，从而基于同一套Kubernetes集群提供面向业务的多个逻辑上独立的环境。

对于一个自动化的部署流程，我们期望是可以在分钟级别完成整套独立环境的创建，各项基础服务的开通，数据资源容器的拉起和数据初始化以及应用的启动。并且整个流程的执行是可以动态创建和监控的，从而可以同时作为一个 工具 服务提供给外部自动化测试以及 软件工程管理系统 （PS：软件工程思想也可以沉淀为一个系统）使用。

前在业务团队中，开发与测试还是遵循比较传统的分工方式：开发完成代码修改，在测试环境或者本地完成简单功能验证后提交测试部署和完成测试验收。其中的自动化过程主要有单元测试，集成测试和系统测试。通常开发只负责单元测试和部分可在本地运行的集成测试自动化，其余涉及数据准备和环境部署的测试代码通常由测试团队完成和维护。 当我们需要一个敏捷团队以最快的速度来交付稳定的产品时，这种模式无法很好的帮助我们的业务开发团队在保证高质量的同时提高交付速度：

1. 测试开发分离，需要更多的沟通和协调；
2. 可用环境有限，提测需要排队，多个不同功能分支无法并发执行测试；
3. 反馈周期长，开发阶段不能发现的问题需要等到提测合并到发布分支后才能得到反馈。

对于开发阶段， 单个应用的自动化集成测试 ，主要需要关注的问题包括：

1. 测试环境应该尽量只包含待测应用和相关基础服务依赖，如数据库、缓存等， 其余需要依赖的服务尽量以mock形式配置 ，减少不确定性和环境复杂性；
2. 测试环境可以随时可重复的创建和销毁，保证环境和测试的可重复性以及有效利用资源，更多的运行测试；
3. 应用的行为可以通过参数化的方式来配置或者实时控制（例如通过配置中心下发配置改变应用行为）。

测试一个服务时，如果上下游不稳定/没开发完

1. 服务氛围稳定版本和开发版本，确保待测服务 上下游服务 都是稳定版的服务
2. mock 上下游服务，将待测服务和mock 服务打包到一个单独的环境

PS：古代女子出嫁，会有陪嫁丫鬟，新环境用老人（对应第一种方案）。《射雕》里完颜洪烈 直接给包惜弱 把杨家村给克隆了一遍（对应第二种方案）。