“DevOps的价值是又快又好地交付软件”

——《凤凰项目》的作者Gene Kim和《持续交付》的作者JezHumble

当前数字化转型的形势下，软件行业面临着巨大的市场机遇，而软件系统复杂度不断增加，跨地域高效协作、多环境部署等问题也逐渐突出，DevOps能帮助企业提升软件研发效率，通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加快捷、频繁和可靠。

基于此，我们策划组织了2期【DevOps职业认证训练营】，并邀请到姚冬、卜汉东两位专家老师全程陪伴学习与答疑。在整理问答的过程中我们发现，学员提出的问题覆盖了规划设计、开发集成、测试、部署发布、运维监控等DevOps落地实践中的关键疑点与难点。

本文从中挑选整理了60个精华问答，分为上下两篇，希望通过这些问题与解析，帮助更多DevOps实践者解决DevOps落地过程中的疑惑与痛点。

[  /forum/thread-109076-1-1.html]（点击下载pdf文档方便阅读）[/url]

一、端到端DevOps概览

Q1：华为端到端的DevOps工具链是如何承载敏捷和DevOps相关理念与方法的？

A：敏捷和DevOps的理念其实是相通的，DevOps可以视作敏捷的延伸，敏捷思想打破了需求与开发之间的壁垒，DevOps则通过将开发与运维间的壁垒打破，打通软件交付全流程。

华为云DevOps工具链DevCloud包含了从需求管理到代码托管、构建部署、测试等一系列步骤，覆盖软件开发全生命周期。理念往往需要结合实践，我们可以通过DevCloud进行需求管理、每日站会等等许多敏捷实践，通过提交代码可以触发执行流水线，让开发人员专注开发。

Q2：华为云DevCloud与传统基于开源组件拼接的工具链，有什么差异优势？

A：传统的由开源组件拼接而成的工具链，大部分都是使用Jira来进行需求管理、用Git来做代码托管、用Jenkins做DevOps开发，因为其组件大部分都是开源的，所以一般费用较低或免费，其缺点是使用者需要掌握很多工具，而且这些工具并不是在同一个平台上。华为云DevCloud是一站式的软件开发平台，可以做到所有工具都在一个平台上，端到端打通覆盖整个软件开发全生命周期。

用Jenkins的人都知道，在使用之前首先需要搭建一套Jenkins的环境，还需要定制化地做一些脚本、配置等，华为云DevCloud相当于是一个已经封装好了的DevOps开发工具，可以极大减少这些操作。在华为云DevCloud里，将编译构建、部署任务等做成了原子化的操作，如果我们想要做Tomcat部署，可以直接使用这些模板，只需要对里面的步骤进行细微的调整即可。而且它还使用了可视化视图，操作起来一目了然，学习成本也比较低。华为云DevCloud还支持代码检查、自定义shell、Python、脚本、自定义report展示。

Q3：DevOps /敏捷和SDLC 有何不同？

A：DevOps/敏捷和SDLC的角度不一样。SDLC是指系统生命周期，它提出的几种典型生命周期模型包括瀑布模型、快速原型模型、迭代模型。而敏捷和DevOps是开发方法和实践，敏捷打破了需求和开发之间的沟通壁垒，DevOps则打通了整个软件交付的全流程。

Q4：DevOps人员在与项目的结合中是否会承担更多开发、测试、运维的工作？

A：DevOps不会让人去承担更多开发、测试、运维的工作。DevOps里有一个理念：让开发的人专注于开发、测试的人专注于测试、运维的人专注于运维，所有的工具层面的东西全部交给工具，只要把一切可自动化的东西自动化，所有的人忙自己手头的工作就好了。

Q5：DevOps的反模式有哪些？

A：参考[  /blogs/104071]《9种DevOps团队结构适用类型与7种反型》[/url]

Q6：DevOps适合哪些行业的业务模式？对于非软件行业是否需要调整模式?

A：DevOps也好，敏捷也好，其初衷和理念适用于所有行业，但是每个行业在执行和实际落地效果上会有一些折扣，比如持续交付的生产环境、自动化部署、质量管控、自动化流转等过程的实现等。

简单而言，互联网的一些应用，或者说SaaS应用，相对来说更适合DevOps的研发模式。原因是：其业务对软件更新、发布的要求较高；没有太大的历史包袱；相对更容易对标目标受众群体，包括生产环境等。

传统类的业务比较重，比如银行的核心系统，实践起来相对较难，也不是说不能用敏捷或DevOps。比如持续集成、每天多次构建、多次提交代码、自动化测试、可视化等，都可以实行。

对于非软件行业，如硬件、嵌入式、机械类，实践起来也比较难，比如测试自动化等，需要做一些工具或平台的适配，引进插件或工具后，流程也能够跑起来，只是会慢一些。

综上，我认为敏捷和DevOps本身是一条没有终点的路，所有行业都可以到这条路上来，只是走得难易与远近的问题。

Q7：在企业落地DevOps有没有什么套路？

A：企业实际情况各不相同，落地DevOps没有统一的套路，但会有一些建议的方式。DevOps偏工程侧，通常建议先把版本管理建立起来，比如Git代码仓、代码分支管理等；接下来需要把流水线构建起来，在上面逐渐进行自动化测试、分层测试等。

Q8：最能有效促进Scrum团队本身持续改进的实践有哪些？

A：每个团队遇到的问题都是不一样的，如果一定要找一个通用的答案，首先要保证团队每日站会、评审会议等如质如期进行，以此来保持持续改进。

二、持续规划与设计

Q9：基于DevOps实现持续有效规划应该先从哪个层面入手？

A：首先需要理解DevOps和敏捷的含义，我们一般说的规划与设计更偏向于敏捷项目管理中涵盖的需求和计划。狭义的DevOps主要是CI/CD，即持续集成和持续部署，是偏工程侧的。广义的DevOps，即本课程中讲的DevOps是“端到端的DevOps”，从持续集成/持续部署，向前延伸到业务侧，向后延伸到运维/运营侧，因此也涵盖了前端的需求和设计层面。

回到问题，基于DevOps实现持续有效规划，应该从需求和计划切入，包括整个的市场分析、目标 体的用户画像，用户的痛点是什么，针对这些痛点提供什么样的功能，然后到产品应该怎样设计，接下来才真正落到研发这个主体上。

从方法论角度来看，需求和设计层面的方法论包括设计思维、精益创业等。做好需求分析后，就要进行需求拆分，排列优先级，这样就进到敏捷项目计划里，方法论包括看板、Scrum等，大规模团队敏捷框架如SAFe等。

Q10：Scrum、看板和 XP 是敏捷开发的具体方式，其区别是什么？

A：参考文章[  /forum/forum.php?mod=viewthread&tid=23370]《DevOps VS 敏捷：傻傻分不清楚》[/url]。

Scrum和看板更侧重在团队级敏捷项目管理层面，XP更偏向于工程实践层面。

Scrum和看板两者比较：“标准的”Scrum包括3355的框架；看板源自丰田的精益生产，其背后是精益的思想，通过可视化、限制在制品的数量，快速 问题和瓶颈点，集中对最严重的瓶颈点进行修复，然后去寻找下一个瓶颈点。DevOps的很多理念同样借鉴了精益的思想，个人认为，看板可以应用到很多领域。另外，Scrum和看板在实施或应用时并没有冲突，可以结合起来使用。

Q11：企业组织架构中什么角色或部门适合推行DevOps落地？

A：企业组织架构中一般都没有专门的组织来推行和落地DevOps。DevOps包括两个部分“Dev”和“Ops”，就是指开发部门和运维部门。企业中推动DevOps的几种常见情况：

• 如果是由开发部门来发起DevOps落地，就是由开发往运维去推进。我们平时看到比较多的是测试团队或传统的质量管理部门来发起，从开发到测试再往前一步到运维生产环境上去，因为这些部门本身就承担着代码托管、编译构建、自动化测试等职能。
• 而有的公司会把内部的基础设施、IT支撑、测试等放在数据中心，往前去推把自己变成类似我们讲的DevOps工程师，然后通过自动化工具帮助开发团队进行自动化部署等，这就是从运维侧往前推进DevOps落地。
• 还有一种情况是近年来比较火的云原生，架构师更多考虑采用微服务架构，通过基础设施即代码等方式自动化部署到Docker环境中，因此引入自动化流水线、Infrastructure as Code（基础设施即代码）、接口测试等实践，这些都属于DevOps的范畴。
• 还有一些其他的角色，比如敏捷教练、内部的技术教练等，他们本身就在做研发管理的落地实践，可以很自然地转化去做DevOps推进。
  
  

综上，DevOps的推进和落地不一定非要有一个DevOps工程师或独立的DevOps团队，初期引入DevOps的时候需要有一个团队或角色去承担起这个职责，进行概念和实践的导入和探索，这时更容易把DevOps工程师、DevOps团队建立起来。而后期应该把这些工程师或能力分散到各个团队中去，让DevOps在企业内有更广泛的传播和实践。

Q12：请问在Scrum中，如果没有项目经理，是由TeamLeader还是ScrumMaster协调资源？

A：应该由TeamLeader来协调资源，ScrumMaster不是管理角色，而更多的是一个辅助的牧羊犬的角色，在Scrum实施过程中守护团队Scrum流程不受干扰。

Q13：对于非产品形态的项目，Product Owner来自哪个部门更合适？（业务部门/研发部门）

A：ProductOwner代表客户，一般是哪个部门更接近业务，更了解业务和系统，就由这个部门的人来担任。非产品形态项目的ProductOwner，要求既了解业务又懂技术，一般可以由业务分析师、PMO等角色担任。

Q14：实际开发中，客户往往无人承担PO的角色，而是领导来承担，如何破解这个问题？

A：这种情况可称为“BDD”，Boss-Driven Development，老板驱动开发。好处是至少有一个人能拍板；坏处是拍板的人，你可能很难去辩驳或谈判，所以最好还是能够把客户侧的人拉进来。当然，如果老板确实对业务非常了解，也非常专业，并且是一个可沟通的人，也是可以的。PO的核心要求是需要有一个人代表客户或业务侧，针对需求或范围做决定，且当团队有问题的时候，可以随时找到这个人。

Q15：影响地图主要应用于哪个环节？

A：从HE2EDevOps实施框架图可以看到，在端到端的DevOps实践中，影响地图通常用于需求规划或业务规划阶段，与传统的Scrum流程相比，更偏业务侧。影响地图通过四层结构：why、who、how、what来拆解业务和需求，也可以用于运营或项目冷启动环节。

Q16：如果一个大的Story拆分成多个小的Story，甚至再次拆分成孙子辈的Story，如何更好地表示它们之间的关联关系？

A：Story拆分有两种方式：一种是从epic（史诗故事）到feature到story的拆分，epic以月为单位，feature以周为单位，story以天为单位；另一种是平级拆分，所有拆分的故事全部叫story，只不过它们之间存在父子关系。不管是三层还是四层，我们只关注父子关系，从一个父story拆分出子story，如果粒度不够小，则以子story为父story继续拆分出它的子story。如果系统需要有层级追溯，可以用树状或脑图等结构来展现。

Q17：学完课程感觉用户故事和项目管理里的工作包很像，二者有个共同的问题，拆解到什么粒度是好的用户故事？

A：故事也好，需求也好，只是一个名字，用户故事之所以叫用户故事，有两点表征：1）它是站在用户的角度去看；2）它讲了一个故事、一个场景。好的用户故事遵循INVEST原则，即一个合适的用户故事应该是独立的（Independent）、有价值的（Valuable）、可讨论的（Negotiable）、小的（Small）、可估算的（Estimable）和可测试验证的（Testable）。

Q18：如果采用敏捷开发，最终的用户需求如何呈现给用户？如果是需要存档的用户需求说明书、设计说明书或操作手册之类的文档，适合从DevCloud导出后再修改么？另外如果出现变更，如何确保文档与代码一致？

A：如果是需求文档，可以以用户故事的形式存放，华为云DevCloud或者其他工具都提供多元的存储格式，如文本、图片、附件等，华为云DevCloud有一个帮助网站，每一个新上线的功能都会在这里进行同步和更新。

也可以把词条或需求存放到wiki里，并跟前端的需求条目之间建立链接。wiki本身是可以有层级关系的，可以把需求从wiki里导出来形成文档形式，如果做得好，还会有版本计划，比如版本里包括10条需求，可以统一导出一篇需求规格说明文档。

需求和代码之间的同步，可以通过流程等方式去控制，比如发版的检查点，这可能需要以人工方式去做，但也可以通过一些工具来辅助。比如提交代码的时候需要提交注释，可以把这个注释关联到一个工作项上，一个需求可能会修改多个文件里的多段代码，这其实就是一个完整的变更集的概念，这个变更是为了同一个目的，是有相关性的，如果要从代码里去剥离的话，应该会把这一次变更集统一进行剥离。在未来查看代码时，可以进行代码版本比较，看两个版本之间进行了哪些增加/修改、这些变更是为什么目的、其意图是什么。

Q19：对于变化的需求或者新增的需求，是应该放到当前迭代里，还是规划到后面的迭代里，持续规划是指规划过程贯穿整个生命周期么？

A：变化或新增的需求都会统一放到一个大的池子里，我们称之为product backlog（产品待办事项列表），这是一个一维的表格，所有需求按照优先级排列。我们要通过判断新进需求的优先级，看它应该放在什么位置。敏捷强调需求是动态变化的，我们会定期对需求列表进行梳理，看是否需要进行优先级排序的调整，

因此变化或新增的需求不会放到当前的迭代里，因为当前迭代是一个固定的时间窗口，且范围相对固定，团队对此进行了承诺。我们会将其放入大的需求池，是在下个迭代还是之后的迭代实现，取决于该需求的优先级。

Q20：对于初学者刚刚接触一个项目，但是项目的需求不明确、结构不成熟，怎么从敏捷入手？

A：这里包括两种情况：初学者、项目在初级阶段。如果是初学者，应该通过获取现有资产快速熟悉和上手；如果项目处于初级阶段，需求也不太明确，可以通过敏捷的快速交付、精益的MVP等实践，快速获取反馈，对后续工作进行指导和建议。

Q21：作为整个项目的入口，需求的质量如何把控和评测？

A：明确定义需求可以转开发的标准，即DoR。那什么是DoR呢？敏捷开发发展了几个年头之后，人们发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代的失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，就是Definition of Ready，简略称之为“DoR”， 最初的Ready是指准备好可以进入迭代开发。

Q22：持续规划与设计有什么度量数据或指标用于衡量团队绩效或用于持续改进？如何衡量持续规划与设计的成熟度？

A：度量工具推荐Scum的燃尽图、看板的累积流图。研发效能的核心度量数据指标包括团队速率、Lead time，即需求的平均交付时长。

Q23：敏捷下的组织过程资产（配置、文档等）有好的存储方案么？

A：理论上文档、资产等都存储在资产库里，常用的知识库或资产平台有Conflunce、IBM的RationalAsset Manager等。资产和知识是不同的概念，现在做资产管理的相对少一些，知识库可以用wiki等平台，便于统一维护更新和协同。

Q24：DevOps 持续规划与设计在DevOps生命周期中是处于开始的时刻，为什么还说代码集成是整个DevOps生命周期的核心呢?

A：“代码集成”包括两部分：代码和集成。

整个软件生命周期包括三个版本：需求版本，即发版计划；代码版本；上线发布的二进制包的版本。其中代码版本处于承前启后的中间位置，且是唯一真正有价值的。需求和文档是没有价值的，只有由代码编译成二进制包并部署上线才是有价值的。在代码层面多花一些精力是非常有必要的，所有的研发其实都是在一个代码仓库里进行协同开发，包括代码版本管理、分支管理等模式，因此将代码视为DevOps生命周期的核心也是必然的。

软件研发最痛苦的地方往往是在集成层面，一开始大家各写各的代码，一旦要将这些不同的代码进行集成的时候，问题就出现了。持续集成的概念来源于XP，Kent Beck 说过“如果代码集成是一件非常痛苦的事情，那我们就每天多次地进行。”一切杀不死你的都会让你更强大，持续地进行集成，你会想办法去减少集成的痛苦。就像跑步一样，假如以前的集成是一块大石头，每天多次集成就相当于将这块石头变成一颗颗的小石子，大石头打在身上会非常疼，小石子就好多了。这也是我们为什么要把集成往前提，并且持续去进行的原因，所以在DevOps生命周期中持续集成也非常重要。

三、持续开发与集成

Q25：如何加强开发人员对于版本质量的信心？

A：加强对版本质量的信心，不只是针对开发人员，对所有人都应该如此。整个DevOps的过程其实就是在保障整体的版本质量，包括静态代码检测、接口API测试等。

另一方面，版本对需求的映射关系或完成程度，应该从业务场景往下去切，看整个需求的匹配程度。

第三点应该是我们通常说的非功能性需求（Non-functional requirements），比如负载、性能、安全、并发支持等，这些要根据我们服务承诺的质量来做相关措施。

Q26：敏捷开发相比传统开发有什么优点？

A：我认为最大的优点或特点是敏捷开发更真实，或者说它更愿意承认研发的本质或现状。

传统的研发认为质量受三个因素制约：范围、资源、时间，且默认范围和资源投入是相对确定的，时间是变化的。然而，在真实场景或变化的市场下，时间和资源是固定的，没办法讨价还价，因为市场、业务、客户都不会等你，在这样的前提下，软件的需求或范围实际上是可以商量或讨论的，我们要以可变的范围去赢得市场、时间窗口。

敏捷开发要求我们不断交付高优先级的需求，并获取反馈，不断调整。这是敏捷开发的最大的核心，承认市场是变化莫测的，需求范围是可变的。

Q27：一个产品，既有主线版本，又有很多的行业定制分支（50+），适合什么样的分支策略？

A：这种场景在传统的产品里比较常见，个人认为应该考虑的是产品策略而不是分支策略。如果分支非常多，会导致产品碎片化严重。

我们在持续集成、持续交付的时候，推崇主干开发或短的分支，不希望这些分支长期存在，否则在产品进行合并时会非常痛苦，工作量也会随着分支的多少和分支存在的时间呈几何倍数增长，所以不建议用长期存在的分支。

那可以用什么样的方式来解决这个问题呢？首先要看整个版本上是否一定要出现这么多定制化的分支，这些分支有没有可能通过配置文件、功能开放等方式处理或实现。举个例子，我们做项目管理的软件，每个客户要求的字段、功能流转的流程都不太一样，如果都通过代码实现，有多少客户就会出现多少个分支，可能都不止50个。

我们是怎么做的呢？针对字段，我可以配置一个界面，里面包括常见属性的字段，这个字段可以是文本类型或下拉框等形式；功能流转的话，新进来一个需求，它的下一个状态是什么、应该触发什么动作、应该是什么样的角色来触发这个动作等这些都是可以进行配置的，这些配置信息存在数据库里，变成用户的配置数据，这样我的主代码主程序是保持不变的，只需要提供一套模型根据数据去驱动适配或实现。这是我们更推崇的方式，可以用来消灭那些分支。

Q28：日常项目开发，在代码分支管理上经常疑惑用什么分支管理策略，比如是选择基于生产分支工作流，还是基于环境等等，在实际实践中，我们应该重点考虑哪些因素？既可以兼顾管理效率，又可以确保代码质量。

A：个人建议采用分支开发主干发布或分支开发分支发布的分支管理策略。基于环境进行分支构建的话，以前我们会有代码库、开发库、测试库等三库管理的概念，但现在全部是持续集成、自动化部署，就没必要再基于环境去拉取分支了。

如何保证代码质量，我们在CI/CD流水线、自动化部署和构建的同时需要考虑每一个环境上跑哪些测试，这些测试大部分通过自动化的方式实现，也有少量的是手工进行。

Q29：像华为云这样团队成员能力超强、应用场景以线上服务为主，一般会采用什么样的分支管理模式？

A：华为云团队也是采用特性分支的管理模式，同时会做多级流水线触发不同环境的流水线来做相关构建，除了开发环境的流水线以外，还有测试、类生产环境等流水线。

Q30：要做到主干上的提交始终处于可发布状态，不受隐含的代码冲突、提交的feature只部分完成等因素影响，对开发团队和基础设施有哪些要求？

A：首先主干上提交的流程或质量要严格控制，真正达到DoD（Definition of Done）的标准，这里可能需要一些机制人为地进行管控，比如Committer机制等。提交的时候，除了非功能性的要求，比如跑相关的回归测试、代码检视以外，还有很重要的功能性要求，比如对需求的实现程度的检查。另外“基础设施即代码”，还要看持续集成、持续部署、自动化测试能不能快速有效地跑起来，并保持高度一致。

Q31：持续集成的成功因素是什么？

A：持续集成主要包括代码仓库、自动构建、自动部署、自动测试四个方面。要求每人每天都要向主干提交代码，触发自动构建和自动部署，在类生产环境进行自动化测试，同时需要团队每个成员确保清楚正在发生的状况，以此来保证持续集成的成功。

Q32：华为云上的CI/CD与K8s上搭的CI/CD有什么区别？

A：华为云DevCloud打通了端到端的软件交付全流程，集成了常用的DevOps开发工具，不仅可以完成CI/CD，还可以直接在上面进行项目管理和开发；而K8s只是软件开发中一个单独的工具，没有项目需求管理等功能，需要配合其他工具一起使用才能实现完整的软件开发与交付。

Q33：开发和修复bug的工时如何进行安排呢？之前迭代出来的bug是按照单独工时安排，还是统一安排在开发中？

A：主要看发版的标准和要求是什么，通常来说可以带病发版，但如果是非常严重的缺陷，就不能上线，必须先修复这些bug。一般bug会跟需求放在同一个池子里，根据它的优先级和影响程度来进行排序，决定是先修复bug还是先做需求。如果修改bug是为了扫清技术债务，建议在一个迭代里固定一定比例的时间来进行。

Q34：感觉SaltStack和Ansible中哪个是最好的配置管理（CM）工具？为什么？

A：两者定位不一样。个人认为Ansible并不是一个标准的配置管理工具，它更多是通过自动化部署的手段去touch环境这一侧，SaltStack相对来说功能性更强一些。

Q35：在代码互评审和评审流程中如何高效地提升代码质量？

A：人机结合，将重复性的，比如检查代码风格、命名规则等工作交给工具；人工集中看代码实践的逻辑、对需求的匹配等。将人从重复性的工作中解放出来，节约时间和人力。

华为实行代码审查Committer机制，开发人员提交代码后，会自动拉起自动化代码检查。提交一个PullRequest，工具匹配相关的review进行评审和打分，如果是重要实现还可能会有一个评审会议，然后进入最终Committer决定是否将提交的代码合并到主干上去。

“DevOps的价值是又快又好地交付软件”

——《凤凰项目》的作者Gene Kim和《持续交付》的作者JezHumble

当前数字化转型的形势下，软件行业面临着巨大的市场机遇，而软件系统复杂度不断增加，跨地域高效协作、多环境部署等问题也逐渐突出，DevOps能帮助企业提升软件研发效率，通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加快捷、频繁和可靠。

基于此，我们策划组织了2期【DevOps职业认证训练营】，并邀请到姚冬、卜汉东两位专家老师全程陪伴学习与答疑。在整理问答的过程中我们发现，学员提出的问题覆盖了规划设计、开发集成、测试、部署发布、运维监控等DevOps落地实践中的关键疑点与难点。

本文从中挑选整理了60个精华问答，分为上下两篇，希望通过这些问题与解析，帮助更多DevOps实践者解决DevOps落地过程中的疑惑与痛点。

[  /forum/thread-109076-1-1.html]（点击下载pdf文档方便阅读）[/url]

一、端到端DevOps概览

Q1：华为端到端的DevOps工具链是如何承载敏捷和DevOps相关理念与方法的？

A：敏捷和DevOps的理念其实是相通的，DevOps可以视作敏捷的延伸，敏捷思想打破了需求与开发之间的壁垒，DevOps则通过将开发与运维间的壁垒打破，打通软件交付全流程。

华为云DevOps工具链DevCloud包含了从需求管理到代码托管、构建部署、测试等一系列步骤，覆盖软件开发全生命周期。理念往往需要结合实践，我们可以通过DevCloud进行需求管理、每日站会等等许多敏捷实践，通过提交代码可以触发执行流水线，让开发人员专注开发。

Q2：华为云DevCloud与传统基于开源组件拼接的工具链，有什么差异优势？

A：传统的由开源组件拼接而成的工具链，大部分都是使用Jira来进行需求管理、用Git来做代码托管、用Jenkins做DevOps开发，因为其组件大部分都是开源的，所以一般费用较低或免费，其缺点是使用者需要掌握很多工具，而且这些工具并不是在同一个平台上。华为云DevCloud是一站式的软件开发平台，可以做到所有工具都在一个平台上，端到端打通覆盖整个软件开发全生命周期。

用Jenkins的人都知道，在使用之前首先需要搭建一套Jenkins的环境，还需要定制化地做一些脚本、配置等，华为云DevCloud相当于是一个已经封装好了的DevOps开发工具，可以极大减少这些操作。在华为云DevCloud里，将编译构建、部署任务等做成了原子化的操作，如果我们想要做Tomcat部署，可以直接使用这些模板，只需要对里面的步骤进行细微的调整即可。而且它还使用了可视化视图，操作起来一目了然，学习成本也比较低。华为云DevCloud还支持代码检查、自定义shell、Python、脚本、自定义report展示。

Q3：DevOps /敏捷和SDLC 有何不同？

A：DevOps/敏捷和SDLC的角度不一样。SDLC是指系统生命周期，它提出的几种典型生命周期模型包括瀑布模型、快速原型模型、迭代模型。而敏捷和DevOps是开发方法和实践，敏捷打破了需求和开发之间的沟通壁垒，DevOps则打通了整个软件交付的全流程。

Q4：DevOps人员在与项目的结合中是否会承担更多开发、测试、运维的工作？

A：DevOps不会让人去承担更多开发、测试、运维的工作。DevOps里有一个理念：让开发的人专注于开发、测试的人专注于测试、运维的人专注于运维，所有的工具层面的东西全部交给工具，只要把一切可自动化的东西自动化，所有的人忙自己手头的工作就好了。

Q5：DevOps的反模式有哪些？

A：参考[  /blogs/104071]《9种DevOps团队结构适用类型与7种反型》[/url]

Q6：DevOps适合哪些行业的业务模式？对于非软件行业是否需要调整模式?

A：DevOps也好，敏捷也好，其初衷和理念适用于所有行业，但是每个行业在执行和实际落地效果上会有一些折扣，比如持续交付的生产环境、自动化部署、质量管控、自动化流转等过程的实现等。

简单而言，互联网的一些应用，或者说SaaS应用，相对来说更适合DevOps的研发模式。原因是：其业务对软件更新、发布的要求较高；没有太大的历史包袱；相对更容易对标目标受众群体，包括生产环境等。

传统类的业务比较重，比如银行的核心系统，实践起来相对较难，也不是说不能用敏捷或DevOps。比如持续集成、每天多次构建、多次提交代码、自动化测试、可视化等，都可以实行。

对于非软件行业，如硬件、嵌入式、机械类，实践起来也比较难，比如测试自动化等，需要做一些工具或平台的适配，引进插件或工具后，流程也能够跑起来，只是会慢一些。

综上，我认为敏捷和DevOps本身是一条没有终点的路，所有行业都可以到这条路上来，只是走得难易与远近的问题。

Q7：在企业落地DevOps有没有什么套路？

A：企业实际情况各不相同，落地DevOps没有统一的套路，但会有一些建议的方式。DevOps偏工程侧，通常建议先把版本管理建立起来，比如Git代码仓、代码分支管理等；接下来需要把流水线构建起来，在上面逐渐进行自动化测试、分层测试等。

Q8：最能有效促进Scrum团队本身持续改进的实践有哪些？

A：每个团队遇到的问题都是不一样的，如果一定要找一个通用的答案，首先要保证团队每日站会、评审会议等如质如期进行，以此来保持持续改进。

二、持续规划与设计

Q9：基于DevOps实现持续有效规划应该先从哪个层面入手？

A：首先需要理解DevOps和敏捷的含义，我们一般说的规划与设计更偏向于敏捷项目管理中涵盖的需求和计划。狭义的DevOps主要是CI/CD，即持续集成和持续部署，是偏工程侧的。广义的DevOps，即本课程中讲的DevOps是“端到端的DevOps”，从持续集成/持续部署，向前延伸到业务侧，向后延伸到运维/运营侧，因此也涵盖了前端的需求和设计层面。

回到问题，基于DevOps实现持续有效规划，应该从需求和计划切入，包括整个的市场分析、目标 体的用户画像，用户的痛点是什么，针对这些痛点提供什么样的功能，然后到产品应该怎样设计，接下来才真正落到研发这个主体上。

从方法论角度来看，需求和设计层面的方法论包括设计思维、精益创业等。做好需求分析后，就要进行需求拆分，排列优先级，这样就进到敏捷项目计划里，方法论包括看板、Scrum等，大规模团队敏捷框架如SAFe等。

Q10：Scrum、看板和 XP 是敏捷开发的具体方式，其区别是什么？

A：参考文章[  /forum/forum.php?mod=viewthread&tid=23370]《DevOps VS 敏捷：傻傻分不清楚》[/url]。

Scrum和看板更侧重在团队级敏捷项目管理层面，XP更偏向于工程实践层面。

Scrum和看板两者比较：“标准的”Scrum包括3355的框架；看板源自丰田的精益生产，其背后是精益的思想，通过可视化、限制在制品的数量，快速 问题和瓶颈点，集中对最严重的瓶颈点进行修复，然后去寻找下一个瓶颈点。DevOps的很多理念同样借鉴了精益的思想，个人认为，看板可以应用到很多领域。另外，Scrum和看板在实施或应用时并没有冲突，可以结合起来使用。

Q11：企业组织架构中什么角色或部门适合推行DevOps落地？

A：企业组织架构中一般都没有专门的组织来推行和落地DevOps。DevOps包括两个部分“Dev”和“Ops”，就是指开发部门和运维部门。企业中推动DevOps的几种常见情况：

• 如果是由开发部门来发起DevOps落地，就是由开发往运维去推进。我们平时看到比较多的是测试团队或传统的质量管理部门来发起，从开发到测试再往前一步到运维生产环境上去，因为这些部门本身就承担着代码托管、编译构建、自动化测试等职能。
• 而有的公司会把内部的基础设施、IT支撑、测试等放在数据中心，往前去推把自己变成类似我们讲的DevOps工程师，然后通过自动化工具帮助开发团队进行自动化部署等，这就是从运维侧往前推进DevOps落地。
• 还有一种情况是近年来比较火的云原生，架构师更多考虑采用微服务架构，通过基础设施即代码等方式自动化部署到Docker环境中，因此引入自动化流水线、Infrastructure as Code（基础设施即代码）、接口测试等实践，这些都属于DevOps的范畴。
• 还有一些其他的角色，比如敏捷教练、内部的技术教练等，他们本身就在做研发管理的落地实践，可以很自然地转化去做DevOps推进。
  
  

综上，DevOps的推进和落地不一定非要有一个DevOps工程师或独立的DevOps团队，初期引入DevOps的时候需要有一个团队或角色去承担起这个职责，进行概念和实践的导入和探索，这时更容易把DevOps工程师、DevOps团队建立起来。而后期应该把这些工程师或能力分散到各个团队中去，让DevOps在企业内有更广泛的传播和实践。

Q12：请问在Scrum中，如果没有项目经理，是由TeamLeader还是ScrumMaster协调资源？

A：应该由TeamLeader来协调资源，ScrumMaster不是管理角色，而更多的是一个辅助的牧羊犬的角色，在Scrum实施过程中守护团队Scrum流程不受干扰。

Q13：对于非产品形态的项目，Product Owner来自哪个部门更合适？（业务部门/研发部门）

A：ProductOwner代表客户，一般是哪个部门更接近业务，更了解业务和系统，就由这个部门的人来担任。非产品形态项目的ProductOwner，要求既了解业务又懂技术，一般可以由业务分析师、PMO等角色担任。

Q14：实际开发中，客户往往无人承担PO的角色，而是领导来承担，如何破解这个问题？

A：这种情况可称为“BDD”，Boss-Driven Development，老板驱动开发。好处是至少有一个人能拍板；坏处是拍板的人，你可能很难去辩驳或谈判，所以最好还是能够把客户侧的人拉进来。当然，如果老板确实对业务非常了解，也非常专业，并且是一个可沟通的人，也是可以的。PO的核心要求是需要有一个人代表客户或业务侧，针对需求或范围做决定，且当团队有问题的时候，可以随时找到这个人。

Q15：影响地图主要应用于哪个环节？

A：从HE2EDevOps实施框架图可以看到，在端到端的DevOps实践中，影响地图通常用于需求规划或业务规划阶段，与传统的Scrum流程相比，更偏业务侧。影响地图通过四层结构：why、who、how、what来拆解业务和需求，也可以用于运营或项目冷启动环节。

Q16：如果一个大的Story拆分成多个小的Story，甚至再次拆分成孙子辈的Story，如何更好地表示它们之间的关联关系？

A：Story拆分有两种方式：一种是从epic（史诗故事）到feature到story的拆分，epic以月为单位，feature以周为单位，story以天为单位；另一种是平级拆分，所有拆分的故事全部叫story，只不过它们之间存在父子关系。不管是三层还是四层，我们只关注父子关系，从一个父story拆分出子story，如果粒度不够小，则以子story为父story继续拆分出它的子story。如果系统需要有层级追溯，可以用树状或脑图等结构来展现。

Q17：学完课程感觉用户故事和项目管理里的工作包很像，二者有个共同的问题，拆解到什么粒度是好的用户故事？

A：故事也好，需求也好，只是一个名字，用户故事之所以叫用户故事，有两点表征：1）它是站在用户的角度去看；2）它讲了一个故事、一个场景。好的用户故事遵循INVEST原则，即一个合适的用户故事应该是独立的（Independent）、有价值的（Valuable）、可讨论的（Negotiable）、小的（Small）、可估算的（Estimable）和可测试验证的（Testable）。

Q18：如果采用敏捷开发，最终的用户需求如何呈现给用户？如果是需要存档的用户需求说明书、设计说明书或操作手册之类的文档，适合从DevCloud导出后再修改么？另外如果出现变更，如何确保文档与代码一致？

A：如果是需求文档，可以以用户故事的形式存放，华为云DevCloud或者其他工具都提供多元的存储格式，如文本、图片、附件等，华为云DevCloud有一个帮助网站，每一个新上线的功能都会在这里进行同步和更新。

也可以把词条或需求存放到wiki里，并跟前端的需求条目之间建立链接。wiki本身是可以有层级关系的，可以把需求从wiki里导出来形成文档形式，如果做得好，还会有版本计划，比如版本里包括10条需求，可以统一导出一篇需求规格说明文档。

需求和代码之间的同步，可以通过流程等方式去控制，比如发版的检查点，这可能需要以人工方式去做，但也可以通过一些工具来辅助。比如提交代码的时候需要提交注释，可以把这个注释关联到一个工作项上，一个需求可能会修改多个文件里的多段代码，这其实就是一个完整的变更集的概念，这个变更是为了同一个目的，是有相关性的，如果要从代码里去剥离的话，应该会把这一次变更集统一进行剥离。在未来查看代码时，可以进行代码版本比较，看两个版本之间进行了哪些增加/修改、这些变更是为什么目的、其意图是什么。

Q19：对于变化的需求或者新增的需求，是应该放到当前迭代里，还是规划到后面的迭代里，持续规划是指规划过程贯穿整个生命周期么？

A：变化或新增的需求都会统一放到一个大的池子里，我们称之为product backlog（产品待办事项列表），这是一个一维的表格，所有需求按照优先级排列。我们要通过判断新进需求的优先级，看它应该放在什么位置。敏捷强调需求是动态变化的，我们会定期对需求列表进行梳理，看是否需要进行优先级排序的调整，

因此变化或新增的需求不会放到当前的迭代里，因为当前迭代是一个固定的时间窗口，且范围相对固定，团队对此进行了承诺。我们会将其放入大的需求池，是在下个迭代还是之后的迭代实现，取决于该需求的优先级。

Q20：对于初学者刚刚接触一个项目，但是项目的需求不明确、结构不成熟，怎么从敏捷入手？

A：这里包括两种情况：初学者、项目在初级阶段。如果是初学者，应该通过获取现有资产快速熟悉和上手；如果项目处于初级阶段，需求也不太明确，可以通过敏捷的快速交付、精益的MVP等实践，快速获取反馈，对后续工作进行指导和建议。

Q21：作为整个项目的入口，需求的质量如何把控和评测？

A：明确定义需求可以转开发的标准，即DoR。那什么是DoR呢？敏捷开发发展了几个年头之后，人们发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代的失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，就是Definition of Ready，简略称之为“DoR”， 最初的Ready是指准备好可以进入迭代开发。

Q22：持续规划与设计有什么度量数据或指标用于衡量团队绩效或用于持续改进？如何衡量持续规划与设计的成熟度？

A：度量工具推荐Scum的燃尽图、看板的累积流图。研发效能的核心度量数据指标包括团队速率、Lead time，即需求的平均交付时长。

Q23：敏捷下的组织过程资产（配置、文档等）有好的存储方案么？

A：理论上文档、资产等都存储在资产库里，常用的知识库或资产平台有Conflunce、IBM的RationalAsset Manager等。资产和知识是不同的概念，现在做资产管理的相对少一些，知识库可以用wiki等平台，便于统一维护更新和协同。

Q24：DevOps 持续规划与设计在DevOps生命周期中是处于开始的时刻，为什么还说代码集成是整个DevOps生命周期的核心呢?

A：“代码集成”包括两部分：代码和集成。

整个软件生命周期包括三个版本：需求版本，即发版计划；代码版本；上线发布的二进制包的版本。其中代码版本处于承前启后的中间位置，且是唯一真正有价值的。需求和文档是没有价值的，只有由代码编译成二进制包并部署上线才是有价值的。在代码层面多花一些精力是非常有必要的，所有的研发其实都是在一个代码仓库里进行协同开发，包括代码版本管理、分支管理等模式，因此将代码视为DevOps生命周期的核心也是必然的。

软件研发最痛苦的地方往往是在集成层面，一开始大家各写各的代码，一旦要将这些不同的代码进行集成的时候，问题就出现了。持续集成的概念来源于XP，Kent Beck 说过“如果代码集成是一件非常痛苦的事情，那我们就每天多次地进行。”一切杀不死你的都会让你更强大，持续地进行集成，你会想办法去减少集成的痛苦。就像跑步一样，假如以前的集成是一块大石头，每天多次集成就相当于将这块石头变成一颗颗的小石子，大石头打在身上会非常疼，小石子就好多了。这也是我们为什么要把集成往前提，并且持续去进行的原因，所以在DevOps生命周期中持续集成也非常重要。

三、持续开发与集成

Q25：如何加强开发人员对于版本质量的信心？

A：加强对版本质量的信心，不只是针对开发人员，对所有人都应该如此。整个DevOps的过程其实就是在保障整体的版本质量，包括静态代码检测、接口API测试等。

另一方面，版本对需求的映射关系或完成程度，应该从业务场景往下去切，看整个需求的匹配程度。

第三点应该是我们通常说的非功能性需求（Non-functional requirements），比如负载、性能、安全、并发支持等，这些要根据我们服务承诺的质量来做相关措施。

Q26：敏捷开发相比传统开发有什么优点？

A：我认为最大的优点或特点是敏捷开发更真实，或者说它更愿意承认研发的本质或现状。

传统的研发认为质量受三个因素制约：范围、资源、时间，且默认范围和资源投入是相对确定的，时间是变化的。然而，在真实场景或变化的市场下，时间和资源是固定的，没办法讨价还价，因为市场、业务、客户都不会等你，在这样的前提下，软件的需求或范围实际上是可以商量或讨论的，我们要以可变的范围去赢得市场、时间窗口。

敏捷开发要求我们不断交付高优先级的需求，并获取反馈，不断调整。这是敏捷开发的最大的核心，承认市场是变化莫测的，需求范围是可变的。

Q27：一个产品，既有主线版本，又有很多的行业定制分支（50+），适合什么样的分支策略？

A：这种场景在传统的产品里比较常见，个人认为应该考虑的是产品策略而不是分支策略。如果分支非常多，会导致产品碎片化严重。

我们在持续集成、持续交付的时候，推崇主干开发或短的分支，不希望这些分支长期存在，否则在产品进行合并时会非常痛苦，工作量也会随着分支的多少和分支存在的时间呈几何倍数增长，所以不建议用长期存在的分支。

那可以用什么样的方式来解决这个问题呢？首先要看整个版本上是否一定要出现这么多定制化的分支，这些分支有没有可能通过配置文件、功能开放等方式处理或实现。举个例子，我们做项目管理的软件，每个客户要求的字段、功能流转的流程都不太一样，如果都通过代码实现，有多少客户就会出现多少个分支，可能都不止50个。

我们是怎么做的呢？针对字段，我可以配置一个界面，里面包括常见属性的字段，这个字段可以是文本类型或下拉框等形式；功能流转的话，新进来一个需求，它的下一个状态是什么、应该触发什么动作、应该是什么样的角色来触发这个动作等这些都是可以进行配置的，这些配置信息存在数据库里，变成用户的配置数据，这样我的主代码主程序是保持不变的，只需要提供一套模型根据数据去驱动适配或实现。这是我们更推崇的方式，可以用来消灭那些分支。

Q28：日常项目开发，在代码分支管理上经常疑惑用什么分支管理策略，比如是选择基于生产分支工作流，还是基于环境等等，在实际实践中，我们应该重点考虑哪些因素？既可以兼顾管理效率，又可以确保代码质量。

A：个人建议采用分支开发主干发布或分支开发分支发布的分支管理策略。基于环境进行分支构建的话，以前我们会有代码库、开发库、测试库等三库管理的概念，但现在全部是持续集成、自动化部署，就没必要再基于环境去拉取分支了。

如何保证代码质量，我们在CI/CD流水线、自动化部署和构建的同时需要考虑每一个环境上跑哪些测试，这些测试大部分通过自动化的方式实现，也有少量的是手工进行。

Q29：像华为云这样团队成员能力超强、应用场景以线上服务为主，一般会采用什么样的分支管理模式？

A：华为云团队也是采用特性分支的管理模式，同时会做多级流水线触发不同环境的流水线来做相关构建，除了开发环境的流水线以外，还有测试、类生产环境等流水线。

Q30：要做到主干上的提交始终处于可发布状态，不受隐含的代码冲突、提交的feature只部分完成等因素影响，对开发团队和基础设施有哪些要求？

A：首先主干上提交的流程或质量要严格控制，真正达到DoD（Definition of Done）的标准，这里可能需要一些机制人为地进行管控，比如Committer机制等。提交的时候，除了非功能性的要求，比如跑相关的回归测试、代码检视以外，还有很重要的功能性要求，比如对需求的实现程度的检查。另外“基础设施即代码”，还要看持续集成、持续部署、自动化测试能不能快速有效地跑起来，并保持高度一致。

Q31：持续集成的成功因素是什么？

A：持续集成主要包括代码仓库、自动构建、自动部署、自动测试四个方面。要求每人每天都要向主干提交代码，触发自动构建和自动部署，在类生产环境进行自动化测试，同时需要团队每个成员确保清楚正在发生的状况，以此来保证持续集成的成功。

Q32：华为云上的CI/CD与K8s上搭的CI/CD有什么区别？

A：华为云DevCloud打通了端到端的软件交付全流程，集成了常用的DevOps开发工具，不仅可以完成CI/CD，还可以直接在上面进行项目管理和开发；而K8s只是软件开发中一个单独的工具，没有项目需求管理等功能，需要配合其他工具一起使用才能实现完整的软件开发与交付。

Q33：开发和修复bug的工时如何进行安排呢？之前迭代出来的bug是按照单独工时安排，还是统一安排在开发中？

A：主要看发版的标准和要求是什么，通常来说可以带病发版，但如果是非常严重的缺陷，就不能上线，必须先修复这些bug。一般bug会跟需求放在同一个池子里，根据它的优先级和影响程度来进行排序，决定是先修复bug还是先做需求。如果修改bug是为了扫清技术债务，建议在一个迭代里固定一定比例的时间来进行。

Q34：感觉SaltStack和Ansible中哪个是最好的配置管理（CM）工具？为什么？

A：两者定位不一样。个人认为Ansible并不是一个标准的配置管理工具，它更多是通过自动化部署的手段去touch环境这一侧，SaltStack相对来说功能性更强一些。

Q35：在代码互评审和评审流程中如何高效地提升代码质量？

A：人机结合，将重复性的，比如检查代码风格、命名规则等工作交给工具；人工集中看代码实践的逻辑、对需求的匹配等。将人从重复性的工作中解放出来，节约时间和人力。

华为实行代码审查Committer机制，开发人员提交代码后，会自动拉起自动化代码检查。提交一个PullRequest，工具匹配相关的review进行评审和打分，如果是重要实现还可能会有一个评审会议，然后进入最终Committer决定是否将提交的代码合并到主干上去。