技术领导力实战笔记_69_第55讲_|_用机器打造迭代机器：现代研发流程体系打造（二）
你好，我是f二CTO兼知晓云负责人何世友。
今天想跟大家继续聊聊打造现代研发流程体系这个话题，并将着重跟大家分享其中，用机器打造迭代机器这一部分内容。
在上一篇文章里，我们分析了研发流程中的关键环节，并给出了对应的解法。
他们分别是，一、高速运转的传送带，也就是现代化的项目管理工具。
二、可追溯的迭代，也就是通过传送带将每一次迭代的产物，如代码提交、架构设计、变更测试、构建部署等，串联并存储起来。
三、重要角色的沟通，也就是用一个通用平台，如slack,在解决人与人之间通讯的基础上，重点解决系统工具与人之间的沟通问题。
四、用机器打造迭代机器受限于文章的篇幅上篇文章中只是简单说到了，因为迭代的步骤很多，所以要让机器包揽大部分环节，估计很多读者并不能十分感同身受。
本文呢将对此做详细解释。
为什么要用机器打造迭代？机器迭代频率越高，对迭代里的自动化程度的要求就越高。
打个简单的比方，如果项目要求一天迭代两次，测试工程师，就要一天走完两次主流程回归测试，此时人工就是最大的瓶颈。
一个项目分分钟有成千上万个用力，依靠有限的测试人员分拣完成，那就是纯体力活了。
而对质量的要求越高，主流程的覆盖范围就越广。
但就这一个环节，如果没有机器的参与做自动化，就会成为一个不可调和的瓶颈了。
之前提到构成自动化流程的大部分工具都是现成的，可以花合理价钱买到的。
本文就将重点介绍研发流程里的各种工具们，以及不同场景下的具体选型。
由于这些工具被正确配置完成之后，拥有脱离人工干预。
在不断电的情况下，自我运转的能力，我们亲切的称之为迭代。
机器里的机器们先来看迭代机器里的流水线，从编码到代码审查，到静态检查，到单元测试，到测试，到构建到部署、到监控，到自动扩容或缩容。
这是一个环环相扣的流水线。
从静态检查开始，每一个步骤都由一个机器角色完成，并推送到下一个步骤，最终完成全程。
一旦其中一环无法完成，则本次迭代就宣告失败，需要返工。
通常这样的流水线呢跑在CI系统上。
Ci系统continues integration,也就是持续集成系统。
常见的CI有jenkins、 bamboo、 solano、 CI等，这些系统各有千修美丑。
本文不赘述。
对比各位可以根据团队背景和成员喜好进行选择，只需要看这个系统是否具有真正意义上的可定制拓展性，以及规模可观的第三方服务的接入支持。
下边将围绕流水线中的几个重要环节进行描述，先来看静态检查、单元测试和构建环节。
这几个环节发生在每一次代码提交之后，由代码版本库的代码提交事件触发执行。
如github bit bucket、 guitt lab的web hook等。
一、静态检查，静态检查由各语言的语法、link工具和bug检查工具组成，前者包括JS的athelent、 python的pylinth等，后者包括java的fidebugs等。
二、单元测试基本上每种语言每种框架都有支持单元测试，如JS的moker、 python的unit、 test、 java的j unit、 go testing等工具本身都都是比较类似各语言开发者都应该很熟悉，难在代码编编时的测试用例覆盖。
这是一个需要仔细权衡覆盖度度、时间的过程，在实践中比较参进测试是测测试，程程参参与到单元测试编写中来。
每一项项目的测试例例评审。
部分用例一定要转化为开发工程师的单元测试，或者说测试工程师需要参参与到开工工程师的单元测试审查和覆盖率。
估估中对应的开发工程师也要参与到测试例例评中。
这二者相结合，黑白盒单元集成测试才能真正有机的为项目质量负责。
三、构建构建是需要开发工程师根据项目的部署策略编写对应的构建打包脚本，例如前端的web pack后端的maving客户端的打包等。
不过基本上要做的事情就是将原本由工程师在本机上跑的脚本移植到CI系统上，这个过程本身不带来多少成本。
再来看自动化测试。
自动化测试由测试工程师维护，由两块工作构成，分别是测试用例管理和自动化测试脚本编写一、测试用例管理、测试用例管理、流行的工具有excel、 cumetrary、 test、 link等。
没错，excel在众多公司中依然是管理测试用例的好工具。
当然，在我们讨论的场景里，excel已经不堪启用管理。
测试用例是为了让测试用例和对应的需求描述，也就是user story关联上，从而让每一轮测试执行，也就是test run的结果。
不论是成功或失败，都自动回传到关联的任务状态里。
同时，平台级的用力管理可以让用力迭代起来，和项目一起生长。
这个前文提到的架构设计文档的迭代一脉相承，甚至用力要作为项目推进中的自动化测试的组织枢纽，串联起自动化测试和实际任务的状态流转。
二自动化测试。
这里的自动化测试主要指的是黑白测试和集成测试和开发工程师维护的单元测试做一个区分。
常用的框架有load、 runner、 selenium、 apim等，这是一个十分耗时耗力的过程。
常见的做法是梳理经过每一次迭代的测试用例，最终形成一个主流程。
用例集主流程的特征是产品特性基本稳定，不会在短期内有较大改动。
测试工程师需要对主流程的测试用例进行测试覆盖，例如通过selenium进行UIUE的用户交互过程录制等。
而有了主流程的覆盖，每次迭代的发布才能够真正的做到push on green.否则每次发版还得测试人员手工回归确认，那就基本是一个跨不过去的时间鸿沟了。
最后来看，部署、监控以及自动扩容或缩容。
一部署devovos的兴起，让运维得到解放。
Docker的流行也让社区疯狂，似乎非docker不可不上容器，就不是好技术团队，其实不见得重要的是达到目的而非工具，一定要根据项目实际情况进行技术选型，不要因为一种便利引入额外的麻烦，目的是什么呢？目的是让机器自己完成自动化部署。
而通过前面介绍的工作，CI流水线上已经有了经过完整测试的构建产物，于是部署阶段只剩下一开启并初始化机器并完成系统环境配置。
通常可以先用预先准备好的镜像文件完成。
该步骤二，上传构建产物到机器上启动服务。
三、将流量或任务分发到新的机器上，四下线旧的机器这里边有机器的运维服务的部署、负载均衡器配置等，每一项业内都有非常不错的工具可以用。
比如我们在爱弗尔，目前用的是，一、使用ensaable完成环境的自动配置，结合AWS的amy镜像，完成机器运维部分。
二、使用fabric结合AWS的code deploy完成的部署流程，并在此基础上完成了auto scale. Aws的code deploy非常好的利用了AWS的基础设施，可以一键完成上面提到的一二三四这几个环节。
而在使用code deploy之前，团队写了一系列脚本去做这一块的工作。
过to scale,常见的做法是在监控系统里定义一系列的metrics设定阈值。
比如过去两分钟内，机器CPU达到百分之六十以上，就是一个完完整的阈值条件定义。
比如过去个域值配置一个动作。
比如过两分钟内机器CPU达到百分之六十以上，部署并上线四台新的应用服务器。
而怎么部署并上线新机器，就是上门的cocode的活了。
二、监控监控分异常监控和性能监控异常监控，配合日志抽集器工作，如前端的century后端的cloud watch、 ch lockily等。
基本的工作原理是从日志中获取错误信息并进行统计，达到设定的阈值就开始报警。
异常监控系统经常对接的是电话告警系统，为oncle的工程师提供错误叫醒服务。
性能监控分微观和宏观两个维度，一APM探针，实时收集应用服务器代码层面的性能信息。
二、监控机器状态、应用服务、响应时间等。
这两者结合可以无死角反映服务状态。
对接到auto scale系统后，可以在大多数情况下完成自动化运维APM探针服务。
常用的有new relic、 app、 dynamics等，国内也有听云one、 APN等一种厂商，区别呢基本上就是价格和第三方支持完备度。
近些年各大云服务商也在做这些周边支持选择上并不是难事儿。
国有一些团队将机器状态等信息归到异常监控里，而我们归到性能监控，主要是站在能否让机器自己治理的角度，毕竟放到异常监控，oncore的工程师更容易醒，但醒了不也是要做scale的事情吗？说到这里，大家在迭代流水线中的各个环节上都用了哪些工具呢？欢迎在留言中告诉我们，供大家参考。
最后呢还有一些待完成和待思考的。
毕竟一台高速运转的迭代，机器中，人类角色才是真正的瓶颈，或者说高速迭代，对人员的要求会更高。
因此，团队的成长便更为重要，也更值得探讨。
坊间有一句话，互联网公司都是轻资产，值钱的，就是人流程代码。
那如何打造一个高速成长的团队呢？希望有机会可以和大家探讨。