这是一个创建于 375 天前的主题，其中的信息可能已经有所发展或是发生改变。
再往前一步，在一个大版本开发的闭环中，产品如何更好地管理、需求如何更好的确定，百度也总结了一些比较好的实践。这些实践一般都方法和工具的集合，同时在实际项目中，将其落地实践，最后归纳总结并分享出来。所以并不是仅有工具就能把所有事情都做好，但没有工具也很难做到。
任何事情想要达成，都依赖于人、方法和工具的结合。
主要能感到这三面墙（上图）的存在，业务和开发之间有一面墙，开发同学可能会有非常深刻的认识。开发和测试之间是有一面墙的，有一些团队可能开发测试间合作比较紧密。但在一些大的产品线上，开发和测试的墙还是存在的。
最后的是测试和运维的墙或叫开发测试团队和运维的墙。今天谈的 DevOps 是要重点拆除的墙。但前面的墙是怎么被拆掉的呢面两位老师讲到：用精益的方法、敏捷的方法去打通前面的墙。
如今大家都在学习 DevOps，可是实践 DevOps 真正解决了最重要的问题吗人表示怀疑。
都在说 DevOps 有一个好处是能让运维自动化、可视化，使得工作更高效，但是 DevOps 只是为了解决运维的问题吗/p>
让价值能快速地流动到客户那里。如果想让价值从前至后快速流动，必须要把前面的墙打掉，若业务和开发那面墙、开发和测试那面墙仍旧存在，即便打通了测试和运维这堵墙也没太大意义。以下有一组数据来证明观点，其实关于 DevOps，国内可能尚未准备好。
真的只剩最后一面墙了/h2>
这是 CSDN 在 2016 年对国内敏捷方法覆盖的一个调查。假设精益、敏捷方法能够把前面的两堵墙打掉，在 2016 年的国内，用 Scrum、用看板、用 RUP 这种方法和实践的企业及团队加起来不到 30%，更多的国内企业或团队一方面是在自己定制的流程，用瀑布的在 20%左右，所以一个结论——去年国内敏捷方法、实践的覆盖率也就 30%左右。
大家会看到企业里面有一部分团队是在尝试使用敏捷方法，但整个企业还处在所谓“敏捷转型”的过程中。
当产品经理决定要做一个功能，首先要写一篇需求文档，然后把文档交给开发同学。写需求文档有各种各样的方法，如写个 Word 文档、或者用 Excel 来管理多个需求点，或者在系统中录入一个个需求卡片，其实这都是常用的方法。
写 MRD 的过程非常痛苦，因为研发同学基本不看，他们更希望你当面讲清楚。写得越长，他们越不愿意看，写得越短的话，他们觉得你干脆给我讲讲就好了，所以总在自问，为什么要写个文档一直在想怎样能更好地把需求管理起来，其实写文档目的是让产品经理的想法快速进入到开发同学的脑海里面，让大家把产品的想法对齐了以后快速进入开发，所以怎样能让这个过程更高效/p>
下图是沟通成效和沟通方式的关系，左下角是沟通方式最“冷”，沟通成效最低的，就是 Paper，文档。说明用文档的形式来传递思想、传递需求的沟通效率是最低的。
打通测试到开发的墙
第二个实践是快速地做计划。严格的 Scrum 流程，要求必须一个一个迭代去做。现实中有许多团队做敏捷开发其实都有自己的开发节奏，除了做迭代，上层还有版本计划，版本上层可能还有里程碑计划。所以工具并没有限制必须采用哪种计划的组织方式，而是大家可以很灵活计划的层级结构，方便把计划做的卡片拖拽到计划中，并且能很方便看到每一个计划里面每人的工作量以及计划总体的工作量。有了这些功能的配合，就能让这个计划做的更快速以及更合理一些。
当实践时首先要有这样的意识：怎样把质量提高家都认为质量不应该由测试来保证，而是应该由开发同学自己搞定。其实在许多外企，如谷歌、亚马逊等，测试角色更多的是提高自动化测试能力，基本的质量保证大多是由开发同学来完成的。百度也是这样学习和实践的。
怎样让产品的质量做的更好较深刻的一点是开发同学自己保证质量，但是仅仅说这句话去告诉每一个开发同学，请你自己来保证质量。这仍不够，还得需要有工具保证这个流程或者保证这个思想的实践和落地，所以在百度效率云中 iCode 的这个产品上做了一些比较严格代码质量保证的功能。
首先是代码提交前的检查。研发同学不能直接把代码提交到一个分支或者一个主干中。在提交代码以后，代码工具先自动生成这样一个评审单，上面首先要做的是自动检查编码规范，如果这次提交的代码没有满足公司的编码规范，那是不允许继续提交的。
其实代码的工作流对于大家来说应该都非常熟悉，如主干开发的工作流，分支开发的工作流。但是仅在团队内部口头约定有这些工作流，效果不会太好，因为这是团队内部的约定，一旦新人进入不知道工作流的事情，可能就把重要的代码分支冲掉了。所以团队执行代码工作流时更好的方式还得需要工具来保障。
iCode 有这样的功能——在代码库管理配置里面，可以开启此代码库的工作流，开启后就强制要求代码库按照工作流去提交，如此设置以后，无论团队有新人进入后者团队有人忘记工作流的事情，研发同学都只要提代码即可，因为入托提交方式不满足工作流的要求，代码是无法正常提交的，同时 iCode 会提醒该如何正确提交。
做代码提交前的严格检查，加上团队代码协作工作流，基本上能保证让开发同学提交的每一行代码都是经过比较严格的质量保证。如此，测试同学就能更好的去专注于一些自动化测试工作。
前两面墙基本上都打掉了，我们终于到了 DevOps 要打掉的这么墙。
打通测试到运维的墙
为了更好的指导自动化测试工作，QA 同学们做了自动化的测试分级。
测试会把自动化测试分成多个级别，根据不同的测试框架、方法、脚本能够对应不同的测试级别，再把不同级别的测试脚本挂载到 iPipe 流水线上，此时大家看到的流线如下图：
在流水线上，代码编译后，经过单元测试、系统测试、性能测试，就会到一个检查点，如之前任发科老师所说，这条流水线不完全自动化，会有一个或多个检查点。并不是每一次提交都要自动上线，而是说可能挑选一次或者几次，最后认为这次功能已经比较完整，然后手动验收测试执行，完成后再去执行后面的任务。
iPipe 让流水线可视化，它能把从开发到测试、发布、再到最后的部署都可视化，可以使团队中的多个角色的信息共享。通过这样一种“半自动”流水线及可视化的方法就能够有效打掉运维和开发和测试之间这堵墙，因为流水线可视化把这些信息串联起来了。
iPipe 工具的思路，就是把各种各样公司内部的、为外部的优秀工具能力都集成上来。测试过程中可以接入多种测试工具、环境资源管理工具，发布时可以对接公司运维部门的多种部署和监控系统。
DevOps 带来了另外一个技术概念是微服务化，目前百度很多产品项目都开始实践微服务化，那么流水线及 DevOps 的工具怎么能够帮助团队去做多模块发布或者微服务的发布和部署/p>
iPipe 采用了这样一种可视化的方法，左边都是每一个代码库微服务模块的版本，然后流水线自动将它集合在一起，去测试、发布、部署。集成的流水线确实是 DevOps 工具的一个重要功能。
举例子，这是我们的项目团队从开发到上线的交付周期的数据，每一个点表示一个 Story，纵坐标表示此 Story 停留的市场，横坐标表示它在什么时间完成的。这个绿色线显示 Story 的交付周期在缩短，说明团队交付 Story 的速度是越来越快的。具体为什么会快呢儿变快了呢者说过去哪儿慢呢过数据分析我们发现有一个测试等待状态的时间，原来是非常长的，大概是 10 天，有了这个数据才能知道——开发和测试的这面墙是存在的。这面墙通过我们不断的努力打没打掉呢后发现打掉了，测试状态等待时常降到了四五天左右，整体交付率有明显提升。
总结
所以说怎样去拆墙没有数据来证明墙的存在以及墙被拆掉是工具能带来的便利，如果手中工具是第三方开源工具搭建出来的，也要思考怎样把这些研发的数据汇集到一起做数据的分析。
此外，之前提到分级测试在公司各个产品线做的如何果想真正 DevOps 起来，就得先把自动化测试、分级测试做了。做了以后还会问做得如何做得好做得不好度也有这些数据帮助团队了解它们的自动化测试完备程度。每一个团队或者每一个大的部门的测试能力数据，像红灯修复时长，测试完备度等，QA 部门都提供很好的数据支撑。当把这些数据给团队看的时候，他们就会比较客观的了解自己的工程能力，从而根据自身的需要主动改进。
所以有了这些方法和实践加上工具的支撑，百度在最近这几年有了一定的工程效率提升，以上都是一些项目的实践，希望对大家能有帮助。
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8578 人正在系统学习中 相关资源：用PS软件给别人腿部增加丝袜裤–HP其他资源-CSDN文库
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！