系列文章：
GOPS全球运维大会深圳峰会于4月21日举行，本文是峰会的第二天会议纪要分享，本文主要包括微服务的架构介绍及QA形式的深度交流问题记录。
一、《基于DevOps的微服务生态系统与工程实践》分享者华为的王磊，《微服务架构与实践》的作者，《DevOpsHandbook》中文译者之一。重点讲解了什么是微服务，微服务的三个原则（以缩短交付周期为核心、基于DevOps、演进式架构），以及微服务的生态系统和工程化实践，偏理论性东西较多。下图为微服务的生态系统：
二、《持续集成交付部署》的深度交流场，主要以QA的形式座谈，问答嘉宾是百度的黎嘉豪和普元的刘相，大家对这个深度交流的反馈都比较好，嘉宾的能力也都较强，记录了几个问题。
Q：持续集成时怎样减小代码冲突，是否有更好的合并分支的实践？（背景一个分支一个feature，几个人开发）
A：分支合并冲突主要原因是分支差异大，迭代周期长，合并时冲突就会比较大。腾讯的经验：腾讯要求一个项目分支7天内要合并到主干，主干的代码每天都要rebase到分支。在架构方面QQ已经成为一个孵化器，QQ周边的所有应用底层架构都用一套，所以底层架构的冲突几乎没有。
开发分支一般分两种方式：1）主干开发，分支发布，一个迭代周期内（2周一个迭代）都在主干上开发，发布时拉分支发布，好处是每天都会构建一个可被PM或老板看的版本，QA也只关注主干的测试即可。如果期间发现bug，因为是在迭代期内，所以在此主干上修改，如果是已发布的版本的bug，基于Release的分支再拉分支修改，修改后要rebase到主干。坏处是前期代码提交时冲突会比较多，适合于小型开发团队，嘉宾黎嘉豪强烈推荐此种方式。
2）分支开发，主干发布，这种常见的冲突是功能冲突，分支1和分支2合并主干后，功能上有冲突，因为各分支不知道互相在做什么事，QA针对于分支的测试可能合并到主干后测试结果与分支的测试结果不一样。
Q：如果公司要践行DevOps，一般都有哪些角色的人？
A：流程人员(一般由敏捷教练担任)、RD、QA、DevOps工程师(负责把交付周期的各个平台和工具串起来)、Gate-keeper(把关人，如产品经理)、OP(准备上线的平台，及平台的配置等信息，并且把信息透漏给RD)。
Q：测试的前期环境及数据准备太麻烦，怎么解？
A：普元的经验分享：业务测试按三角型的层次可以分为：最下层单元测试UT、中间层集成测试IT，最上层场景化集成测试SIT。首先单元测试是必须要有的，08年到10年实行测试人员与开发人员轮岗，通过培训、轮岗、逃汰三种机制给测试人员赋能可以写代码，具备自动化测试的能力，这样搭建开发测试环境及数据准备就不是难事。其次是集成测试，集成测试也是必须的，一般指功能性的集成测试。关于场景的集成测试不能保证都覆盖掉，经验是通过日志分析用户最常用的场景，先把top的场景集成测试做起来。整体测试代码与业务代码的的比例是9：1。分开API测试与UI测试，上面所讲到的都是API测试，UI测试使用Selenium做到了部分自动化。关于UI的自动化测试提到一点比较可取：将测试成功的页面做个snapshot做图片存储，以后每次跑这个页面的测试后的图片与存储正确的图片做diff，如果与预期不符（如弹出错误框）就可以很快的反馈结果。
Q：内部产品版本更新后如何通知几千个用户？虽然有帮助文档但用户都不看，怎么破？
A：引导页、人工智能、爬虫等技术加入到产品支持平台。另外每次版本更新的新功能要写一个比较“逗逼”的文章，或有喜感的PPT，这样宣讲完印象会比较深，其次产品经理要见人就说新功能是什么，不断的“安利”。
Q：Jenkins的Job怎么配置，有什么最佳实践？为什么一个测试的job就要有10多个?
A：JOB创建的准则：RD在提交代码后在20分钟之内对提交的代码有简单的报告显示。单从测试角度说就有UT测试、功能测试、性能测试、压力测试等等，每个测试用1-2个job实现。整个JOB链路可以分为 单元测试、codeReview、API兼容性测试、代码规范检查、安全测试(如数据库连接是否关闭)、分布式编译、发布到质品库、打镜像、发布到沙盒、预发。对于最后集成将以前的push模式改为pull的模式，各个微服务保证自己的流水线构建产出物的稳定（自证清白），集成时采用pull的模式拉取各个微服务的稳定版本集成。因为是各个微服务并行编译，所以会缩短集成时间。
Q：DevOps可视化都做些什么？
A：DevOps最后的精华就是度量、就是可视化。举几个例子：
- IT团队的能力：一个周期内能产生多少个Feature，有多少个产品在做，都在什么阶段、有多少个版本。
- 从工程效率角度出报表，哪个环节影响效率。
- 内部过程数据文档都有记录，不担心关键岗位人员的离职。
