雅纯
探索云世界
雅纯
暂无个人介绍
在前面的分享里，我们了解到本次云效升级，产品形态从工具产品转变为一体化平台，从为散点角色提供工具服务，转向为上下游的角色连接，建立全链路的服务。对体验设计而言，我们也需要从关注单一工具的体验，转为关注全量用户的研发协同体验。目前云效的用户，主要由一线研发、研发负责人、项目经理、产品经理构成，其中研发类角色占比最多。通过调研分析，发现各角色遇到的问题，可分为三类：对产品难以产生认同操作使用不够易用功能认知不足为了提升体验竞争力，更好地服务全生命周期的用户，我们将以专业的办公体验、敏捷的操作体验、可靠的管控体验为目标，进行体验升级。01 专业的办公体验产品使用无障碍是实现专业办公体验的基础，能无障碍的上手和阅读也是本次体验升级的重点。我们认为，因人而异的引导能加快提升产品使用的技能。因人而异是指将用户分层，进行针对性引导。在新手阶段，不用担心使用有门槛，我们提供快速上手教学，帮助建立对产品的积极印象。首先，认知了解产品，通览亮点能力，进行快速体验。其次，产品试用评估，结合步骤式引导体验产品的核心能力。最后，留下使用反馈，让我们更好的为你提供服务。认知了解阶段初进入产品时，通过图文结合的亮点介绍，获知产品的核心能力。了解学习后，开始你的使用体验。试用评估进入示例模块时，可借助步骤式的学习引导，帮助你快速完成重要功能体验，比如一次代码提交、一次部署发布流程，让复杂的研发流程变得简单易上手。使用反馈为了后续提供更有针对性的产品服务，在体验完核心功能，可以留下你的使用感受和反馈，我们在收到后将第一时间为你解决，帮助产品更好的进步。对于非新手阶段的用户，已了解产品的基本能力，不希望被强推信息、频繁打断工作，更关注高阶功能的发现和探索。由此，我们升级了引导形式，按对用户注意力的影响，将引导分为5个强度。从引导强度最高的信息弹窗，到低感知的小蓝点标记，引导度逐级递减，为大家带来更有针对性的分层引导。通过因人而异的设计，让功能上手更专业。同时，我们希望不断改进界面视觉，让阅读体验更专业。专业的阅读体验，需兼顾舒适和效率。过去页面浏览时，存在密度小、留白多等问题，从而造成阅读屏效低。已有研究表明，人眼的舒适眼动宽度为1200px，到12px之间。在此基础上，我们将过去低密度、间距留白失衡的情况，优化为适中密度，减少无效的留白，并扩宽了核心功能区。单页信息量提升 45%，并且控制长文本区的极限宽度，提供最佳视域范围（1200px），避免大屏情况下，左右转头式阅读，让信息密度更舒适。不同尺寸的屏幕下，如何保障同样的阅读舒适？我们进一步探索了阅读适配规则，保证正文可读优先。以代码库首页设计为例，对于除代码正文之外的侧栏信息，当宽度足够时，使用挤压式侧栏保证屏效最大化；宽度不足时，使用抽屉式侧栏保证正文阅读不受挤压影响。在多栏结构的库首页中，文件树和辅助信息两个侧栏，共有4种展开/收起形态。为保证阅读效率不受损，我们结合信息重要度，制定了阶梯式响应规则。从1920的宽屏显示器到 680 的小窗分辨率，我们都以正文可读为第一优先，有序收敛次要信息，让阅读浏览体验更专业。02 敏捷的操作体验为了让产品更好用，我们在操作体验上做了许多努力和优化。下面我通过降低操作成本、缩短操作路径两个案例进行分享。案例1产品经理小宝，平时不仅要写需求、指派任务，还要按发布迭代编写版本说明。这对刚入职的她，带来了不少难度。我们认为，提供一定的内容预设，能够消化输入的复杂度。在需求产出阶段，设计需求模版，便于快速编辑。同时，我们发现拆分任务时，父需求与子任务标题高度重合，仅在后缀上有对象差别。因此，为降低输入成本，将原先需要手动填写的子项标题，默认填充父标题，大家只需微调后缀，即可一键创建，带来工作拆分效率的提升。在发版阶段，同样提供一键插入版本描述模版，轻松写出合规又优雅的版本说明。通过降低操作成本，让内容填写更敏捷。在内容查找上，我们注意到查找效率有很大提升空间。案例2小宝想起来上周的需求要更改迭代，于是她开始打开云效-打开projex-找到项目-找到项目下需求-筛选上周-选择需求-进入编辑，就像是在嵌套的文件夹里找文件。经过了长达7步的下钻，才到达目的地。整条链路上存在着 路径长、跳转多、认知成本高，需要用户对产品有较高的熟悉度。另外，考虑云效用户都是以开发类角色为主，对键盘输入有天然的偏好倾向。于是决策设计全局指令搜索，带来触手可及，随用随走的查找体验。查找前通过产品顶部键位引导，在任何页面可一键激活搜索。首次打开，还可在动态提示下了解更多快捷键位。使用中考虑大家会多数查找当前产品下的内容。由此，顺从习惯，我们提供默认的范围定位，让结果推荐更精准。最终将长达7步的目标查找，缩短为3步点击，5次页面跳转缩短为仅需1次，即可直达最终目的地，实现目标查找，更敏捷。03 可靠的管控体验管控体验的核心在于建立「安全可靠感」，让异常问题掌控、安全风险可掌控。我们洞察到异常问题最常出现在 代码提交到部署发布的链路，这不仅是产品上线的最后一道战线，也是体验反馈较多的链路。主要问题有：冲突问题滞后，在评审发起后才可识别，需要发起人重新修改再提交代码，增大操作成本；合并状态分散，评审人及合并人，难以通览全部状态信息，影响评审决策效率；部署进度不可知，异常提示不直观，操作难干预。如何预知问题，识别异常？1.缩短曝光路径在评审创建阶段，将原先至少需 4 步的冲突解决链路优化为1步，发起评审即可实时定位冲突问题，问题早发现才能早解决。2.聚合状态信息在评审代码阶段，将原先分散在3处的合并条件聚合成一处，整体评审状态可视，一次性解决全部评审问题，大幅提升评审效率。3.部署进度可视针对过去部署信息层级深，进度不可知的问题，通过可视化设计，让部署进度实时可见，已经收到不少的用户好评！通对提交到部署链路的异常管控设计，让问题掌控更可靠。解决问题过程中错删、未保存的情况时有发生。一旦触及到高危信息，误操作会带来不可挽回的后果。比如在配置了一长串权限信息后，没保存就前往了其他模块，反应过来发现配置的内容已经空空如也。为避免同类问题，我们建立容错机制，将删改类操作按安全等级，分为低、普通、高三个安全模式。低安全模式下，在功能附近即可确认操作，如普通成员的删除；普通安全模式，需核对信息后，进行后续操作，如删除任务；高安全模式下，必须输入校验信息，确定是本人才能操作， 比如删库，删项目。有了这层体验保障，相信大家在使用中操作可控，降低不安。通过容错机制设计，让安全掌控 更可靠。结语云效体验升级的核心在于以人为本，用简洁有效的设计，让体验更符合直觉且易用，让大家更便利解决问题。我们也将继续致力于打造更专业、更敏捷、更可靠的先进研发协同体验。云效升级，等待大家去体验和探索！点击云效官网立即体验云效BizDevOps全家桶，基础版免费使用。
前面我的同事分别从需求协作、代码协同和应用发布三方面，和我们分享了如何通过云效完成日常的产品研发。当我们的工作活动都在云效上时，这便就有了度量的数据基础。在很多文章中我们看到的是，效能洞察主要是帮助企业管理者，在研发管理上提升效能。今天我想和大家分享的话题是，如何借助度量数据，帮助我们从点滴处提升工作效率。个人度量助力个人工作效率提升我们都知道，一个产品被创造出来的过程，是很多人一起协作的过程。大家在合作的过程中，经常会出现一些信息差，比如：前线业务同学提了一个客户需求，总是要追问才能知道需求进展怎么样了；项目经理总是要逐一问过去，才能知道各个项目的进展如何，有没有什么风险。我们的测试同学小七也遇到了协作上信息不一致的问题。小七负责多个项目的测试工作，日常很多时间要花在测试设计、测试工作开展上，充当着一夫当关、万夫莫开的角色。做为产品的重要守护者，小七的工作效率很关键。除了日常工作之外，在测试协同上，她也遇到一些问题：这么多缺陷，开发到底修复得怎么样？有没有严重阻塞业务发布的问题？后面还有哪些重要的需求要提测？同时，关于项目质量，老板问起时，也很难准确、针对性的说清楚在以前，面对这些问题，小七的做法无非就是轮番问过去，拿着 Excel 去收集数据，然后做各种透视表、图表，再复制粘贴到报告上，整个过程非常的繁琐和低效。现在，在云效上，各环节数据是打通的，需求、测试和缺陷彼此关联。这样，对于小七而言，一张指标卡就可以看到需求的提测进展和优先级，从而有针对性地进行测试工作安排。同时在缺陷跟进的场景下，也可以通过一张指标卡看到缺陷的修复进展，点击下钻即可看到具体的缺陷内容，从而对缺陷进行相应的处理。同样，项目整体的质量，也可以通过度量报表查看。这样小七再也不用烦恼数据统计的问题了，可以把更多的精力放在测试工作上，守护好产品质量。团队度量让项目进展和工作安排更清晰像小七这样的例子还有很多。我们的技术团队主管的大山，也面临着在团队项目管理任务分配以及效能改进方面的问题，比如：进行中的项目是否有风险？团队成员的工作分配是否合理？是不是平衡的？新的需求进来，如何安排相关同学来承接？针对这些问题，如果没有更多的数据，基本都会是跟着感觉走的。现在，在云效效能洞察上，大山可以通过一个报表，清晰地看到项目的风险和进展：多少需求没有开始？哪些需求逾期了？缺陷修复的怎么样了？结合趋势，可以看到现在的需求交付状况是不是有问题、缺陷是不是收敛，要不要及时进行干预。对于日常的工作安排上，也可以通过一张报表，全面的了解每一个人在各个时间段上的需求、任务进展，一目了然。有新需求进来时，工作安排，也可以做到游刃有余。整体上，在项目跟进和团队工作安排时，可以做到轻重缓急，清清楚楚。跨项目度量让多项目跟进更简单另外，对于项目经理小胡来说，他大部分的工作，都是在跟进项目进度、做项目的一些汇报。这些工作会占据他的很多时间，他在超负荷地跟着好多个项目，风险管理、资源协调都让他头大。最让他头大的事，就是汇报工作了。这个项目要汇报、那个项目也要汇报，每个月要汇报、季度还要汇报。为了汇报，需要收集数据、整理各种报表，费时费力不说，数据完整性、数据细节、指标定义，也经不住老板几次发问，整个就是吃力不讨好。现在，在云效效能洞察上，小胡可以随时开启符合自己场景的项目度量报表，再也不用费心费力地各处收集数据、绘制报表。还可以把报表一起分享给多个老板，不用文件传来传去，容易漏不说，老板找起来也麻烦。报表轻松共享点击指标卡就可以查看数据明细，里面指标定义、数据条件都非常清楚，不用担心老板的层层发问，也不用费力解释了。图片指标卡定义清晰可见如果有特殊统计的场景诉求，还可以自定义报表，新建自定义指标卡，调整报表布局等。这样，时间久了，小胡就能不断积累起来符合自己汇报诉求的报表集合。将这些重复、繁琐的事情交给工具来做的话，一个项目经理，跟几十个项目也不在话下。效能洞察致力于让过程被看见，工作更高效前面和大家分享了几个小场景，云效效能洞察之所以能够在点滴之处帮助到大家，也是源于云效覆盖了软件研发的整个生命周期，从需求设计、编码开发、集成构建、到测试发布等等环节。有了这些过程中全量的静态数据、时序数据，我们才能够更准确、清晰地回答项目交付、研发过程中的问题。有了数据基础之后，我们还要根据场景目标去确定度量指标。指标那么多，哪些才算是好的、有效的指标呢？为了让我们能够更方便的选择合适的指标、配置度量报表，云效效能洞察基于前人的经验，默认提供了几十个场景化指标卡、9个场景化报表模版，涵盖了项目协同、代码协同、工程协同领域，我们可以像搭积木一样搭建自己的度量报表。效能洞察指标库效能洞场景化报表模版度量本身不是目的，改进才是我们目的，期望云效效能洞察能够帮助我们更方便发现问题，及时做出一些改变。点击这里，可申请免费试用云效效能洞察。
一次曲折的发布我们说代码编写完成只是一个业务需求的开始，如何将一个需求快速发布上线、投入生产才是我们的最终目的。我们先从一个案例开始。从前，有个开发同学叫小周，他的一次发布是这样的：首先他要在代码平台手动创建代码分支提交代码，然后要编译构建，有可能是本地构建，也有可能是使用某个构建工具，构建好之后部署测试环境，需要先申请测试机器，然后去机器上执行某个脚本才能启动服务。环境准备好之后才可以交给测试进行一轮、二轮测试验收，这一过程要重复很多次，每一次都要走好几步。验收通过后，发布上线还需要申请发布单，让运维同学帮忙去做发布。这一整个研发过程花费很长时间，需要和很多个角色相互协作，而且需要在很多个平台之间来回跳转，比如代码平台、构建平台、资源平台、运维平台。期间存在资源分散、流程混乱、结果不可预期等等问题，整个过程难以追踪，难以管理。通常一次发布需要持续一天，糟糕的时候一周甚至两周只能发布一次，严重影响研发效率。小周不禁感慨，发布难，难于上青天！问题这么多，怎么办？云效提供一站式应用交付平台，帮你加速应用研发流程，加速应用上云。使用云效后，小周同学的一次发布是这样的：1、收到业务需求，直接进入目标应用，创建应用变更自动拉取代码分支；2、代码提交后自动触发流水线部署开发测试环境；3、部署成功后自动通知测试同学进行测试验收；4、验收完毕，小周同学可以一键点击发布生产，不需要填写申请单，也不需要找运维。使用云效只需简单几步即可完成一次应用发布上线，整个流程更加简单、更加透明、更加顺滑。那云效是怎么做到的呢1、以应用为中心首先云效以应用为中心来组织应用资产。通过应用来聚合应用的源代码、CI/CD流程、构建好的包，如maven包、npm包、docker镜像等等；以应用来聚合基础设施资源，包括线上线下环境的，比如企业自建的机房、在某个云厂商的采购的云主机或者k8s集群。让所有资源都以同一个维度、聚合在同一个平台集中管理。此外，应用还为开发、测试、运维等多角色提供统一协作切面，所有同学都可以在一个应用视图完成主要工作事宜。所有资源所有角色都使用同一个平台，减少各角色在多个平台来回跳转，减少流程割裂，打破了各角色职能壁垒。通过这种方式为企业提供一站式应用交付平台。2、应⽤架构统⼀编排、终态定义小周刚入职时，他负责一个应用的某一个模块，有一天服务启动失败了。他的师兄告诉他，你要先改一下这个配置，然后再修改那个参数，再执行脚本部署才行。一个应用有好几套环境就有好几份配置和脚本，而且好几个人负责同一个应用，经常配置打架，来回改那么几次就完全乱了。每一次的部署结果都不一样，都不可预期，拉起服务就真的只能靠”人品”了。云效以终态编排的方式统一应用的部署架构，改变了原来过程式、步骤式的部署方式，以声明式的方式来定义应用服务，同时支持k8s和主机部署，能够很好的支持应用云原生化转型过程的架构迁移。针对多环境差异，云效支持编排占位符，支持将多个环境差异化的配置抽取成变量，实现一套编排多环境差异化部署能力，消除部署过程中的不一致风险，减少环境配置维护成本。此外云效的应用编排还可以用白屏化、可视化的方式进行，配合应用编排模板，帮助用户快速上手，让小白用户也可以轻松编排并发布自己的应用，降低使用门槛。3、测试环境一键创建、一键销毁服务启动了，是一个好的开始。但我们在日常研发过程中经常会听到这样的声音：谁又动了我的环境？有经验表明：测试和联调任务才是开发日常工作的主要部分，通常占据开发者⼯作时间的50%以上。那么一个稳定、好用的测试环境就非常重要了，它能够极⼤提⾼开发者的⼯作效率和幸福感。云效提供测试环境管理功能，帮助开发者高效自运维：支持测试环境一键创建、一键销毁，无需人肉申请资源，测试资源按需使用，避免浪费；联调过程中支持测试环境一键占用，锁定环境，我的环境我做主，保障测试环境稳定性，让独占稳定的测试环境成为可能。4、多种部署策略、部署过程可观测可干预测试完成后就到最后一步发布了，对于生产发布，云效支持滚动升级、分批发布、蓝绿发布等多种部署方式。通常我们发布上线，会先发一个小的批次，进行灰度验证，验证没问题再逐步放大后续批次。云效支持精细化的分批策略设置，支持手动指定批次数量，精确定义分批过程。此外整个部署过程可以实时查看部署进度，可以查看机器的执行日志。对于k8s部署，我们还支持查看pod关键事件、容器启动日志等，帮助快速发现问题、定位问题。遇到问题时可以一键暂停、一键回滚，保障发布过程的安全性，让开发自运维更可靠。5、研发流程可视化、可管控终于我们的发布流程走完了，小周入职半年后，这一套流程也已经非常熟悉了，这就是我们说的熟能生巧。但个人效率高并不代表整个企业效率高。个人经验能发挥的作用范围，会随着个人的升迁、调动、离职而消失。只有将个人经验流程化，才能沉淀为组织资产，帮助企业提效。云效支持自定义企业研发流程，将企业研发习惯、研发方式通过配置固化在平台上，这样小周就可以把自己的经验落实到平台上。当公司有新人入职时，新人可以一眼看到研发流程，再也去问他的师兄了，也不需要去接手“祖传”的机器、“祖传”的脚本了。研发过程可以快速上手、快速执行，提升了整个企业研发运维活动的规范性、确定性。此外我们日常研发过程经常还会遇到这样的问题，一段没有经过测试验证的代码发布到生产环境了，导致了线上故障。这是一种非常低级又常见的错误，那么有没有办法避免呢？云效支持自定义变更规则，限制只有通过日常测试验收、通过集成测试验收的代码才能进入生产发布阶段，帮助企业守护研发质量。此外云效还支持人工卡点、以及精细化的角色权限管控，让研发流程更安全、更可靠。6、打通业务需求到发布的端到端流程回顾我们整个过程，好像都没有提及到另外一个角色：产品。但其实产品同学无处不在，他每天都会来催你的需求，催你的进度。为什么要催呢？因为他不知道，所以要问。那能否有一个地方让产品同学实时看到进度呢？云效将一次业务需求对应代码变化、配置改变或其他要素改变定义为一次变更，通过变更连接业务需求到发布，串联整个开发、测试、生产整个过程。通过自动化规则实现一旦应用发布上线、应用变更完成、需求状态可以做到自动同步，让业务需求状态和研发进度一目了然。产品再也不用每天来催了。总结云效AppStack可以助力企业：将分散的资源转变为聚合的应用资产，将过程式操作转变为 终态声明式应用架构定义，将运维做发布 转变为开发高效自运维，将个人经验转变为平台固化的流程和标准，实现业务需求的全生命周期跟踪，让应用上云最后一公里更快、更顺滑！有开发同学反馈说，使用云效后，可以一边喝着咖啡、一边听着交响乐，一边做发布，发布再也不用排队啦；运维同学说，使用云效后，所有资源都能在一个平台管理，再也不用好几个平台来回跳了，真正是解放了双手，解放了生产力；产品说，使用云效后，需求进度一目了然，再也不用每天去催进度啦。云效让应用交付可看见、可落实、可传承，让一切井井有条。以上就是我的全部分享内容。如果你希望体验云效AppStack的能力，欢迎前往：devops.aliyun.com 进行体验。以上部分能力仍在内测中，我们将在后续陆续上线。
当我们在项目协同过程中，把要做的需求确认清楚后，接下来就要考虑如何将这些用户故事，转换为可运行的代码程序，这时候就轮到开发者们登上舞台开始表演了。云效代码管理Codeup就是这样一款服务于开发者的产品。在Codeup上，你可以免费托管代码、进行代码评审和持续集成，并通过数据图表跟踪工作进展。目前已有百万开发者和数十万企业正在使用Codeup托管自己的代码。在去年，云效Codeup针对代码安全进行了全面的建设，从存储安全、访问控制，到代码加密、备份，在风险事前、事中、事后提供了全面的安全保护能力。除了为大家保管好宝贵的代码资产外，我们还希望能够帮助大家更高效的工作。因此，今年我们在协作流程方面进行了一系列的改进，让大家能够更高效地互动，更专注地工作，进而实现更早地下班。说到协作，作为开发者，大家可能更喜欢独自一人静静坐在电脑面前写代码的感觉，那是武林高手闭关修炼的感觉。但是，现代公司的项目一般不可能一个人100%就能全部做完，再厉害的武林高手也需要队友。随着队友人数的增加，人和人之间沟通的成本成平方增长，这时候沟通的有效性就变得至关重要了。怎么沟通最有效呢， “ 神级程序员 ” 林纳斯回答了这个问题，翻译过来就是“多说无益，放码过来”。在我们的日常工作中，这种沟通活动被称为代码评审。如何让代码评审更简单代码评审可以集聚众人之智慧，实现1+1>2的效果。没人评审的代码，其水准仅是编码者的水准，而被团队评审的代码，其水准可以超越团队的最高水准。代码评审是个好东西，但实际操作起来并不容易。接下来，我们从评审发起人、评审人和企业管理者的视角，去了解一下他们遇到的烦恼，以及通过云效Codeup如何帮助他们解决问题。1.评审发起人的烦恼首先，对于需求开发同学来说：在创建评审时，他不得不频繁地切出本地IDE，打开浏览器登录代码服务的网页端，填写一堆评审说明和参数，才能完成创建。接着，评审建好了，但因为管理员设置了各种合并的条件卡点，他首先得弄清楚哪些条件还没满足，然后才能逐个去解决卡点。否则代码就无法上线，万一误了迭代周期，可不好和产品经理交代。在解决反馈问题时，由于评审回复是个异步过程，没人知道评审人什么时候有空来评审，特别是几个人共同评审的情况下，评论分散，在动态里一条一条的找甚是麻烦，效率真不太高。使用云效代码管理Codeup之后，他现在可以这样做：无需频繁地切换 IDE，在本地编辑器里直接推送代码，就可以在网页端自动创建一个代码评审，本地和云端链接更加流畅；即使在网页上创建评审时，也支持分支、标题、评审人参数自动填充和描述模板建议，创建评审更轻松；在推进评审的过程中，现在他无需思考太多，在页面可以清晰地看到聚合的卡点条件和实时的达成情况，像打怪升级一样解决掉这些卡点，就可以完成合并，推进评审更加专注。在处理评审人反馈的时候，他无需在分散的时间线动态中寻找蛛丝马迹，只需要关注待解决的事项面板，一眼可见全部待办，处理效率大幅提升。2.评审人的烦恼另外，我们的评审人段誉同学也很不容易：在专注工作时，他经常不时收到评审请求，打断了手上的工作，暂时搁置吧，挤压的评审一多，又不知从何看起；在执行评审时，发现问题基本靠经验，肉眼一行一行看代码还是可能遗漏风险，肩负审查的责任，压力山大；而且，评审交流常常反复，消息通知不及时，沟通效率起不来；使用云效Codeup之后：在安排评审时间方面，现在，他开启了云效的评审耗时预估能力，可以直观地查看每个评审的预估耗时。再根据预估见缝插针地合理安排碎片时间，利用午饭前的10min间隙也可以完成一个评审，执行力更强了。在代码评审的过程中，基于云效开箱即用的自动化检查能力，辅助人工评审，仿佛为代码上了双重保险，让检查更快速，更精细，大幅降低问题遗漏到线上的风险。在针对问题的讨论交流阶段，评审消息可以通过邮件钉钉等方式快捷触达，消息感知更及时，沟通协作更顺畅。3.管理者的烦恼我们的管理者也有一些烦恼。我们来看看他的一份聊天记录：有一天，产品经理在群里着急地催促：咱们功能什么时候才能上线啊，再不上可要被别人抢先了！而开发人员这样回答：功能写完了，但是还在等评审，而且有一些技术部要求的检查还没跑过，需要优化下代码。可是业务第一啊，在残酷的市场上有时候速度就是生死牌，这时候他决定站出来保业务，放弃掉一些质量。在面对迭代速度和工程质量的选择上，其实他心里也很纠结。业务必须跑起来，但是如果不管开发的质量，只会给业务埋下一个一个随时会引爆的暗雷。业务开发既要快又要好，使用云效代码管理之后，现在，他的团队可以根据业务性质自行决定 “扫描的规则” 和 “卡点的规则”，让代码更快地流动起来。在扫的规则上，我们知道，规则并不是越多越好。过多的规则只会给开发团队带来负担，因此选择合适的规则很重要。云效精选了一批规则内置到了产品中，开箱即用，自动触发，包括经过阿里集团多年实践经验总结的阿里巴巴Java开发规约、敏感信息检测、源码漏洞检测等，将我们的经验分享给大家。除了扫描的规则外，他还可以自定义流程卡点的规则。例如对一些必须高速迭代，对工程质量有一定包容度的项目，可以走轻量评审，最低成本做自动化检查，不设置严格卡点，便于必要时快速合并代码。而对于迭代速度相对稳定，且对编码水平有高要求的项目，可设置严格的评审卡点，确保代码质量。使用云效之后，现在他可以在高速迭代的业务下同时兼顾代码质量，从一部分合适的业务开始，逐步搭建起评审规范和流程，然后过渡到更多团队。云效的自动化评审能力，平均每月为每个企业自动发现200多个有效问题。以人工发现一个问题大概需要10min算，累计每月为企业节省33小时的专家人力，让他们可以把时间投入到产生更大价值的事情中去。坚持代码评审就像坚持运动健身一样，不要高估它的短期价值，也不要低估它的长期价值。现在就开始吧，云效将协助你把评审这件事变得更简单。分支协作如何才能更顺畅除了评审代码外，开发者们在分支协作上的互动也非常频繁。我曾经遇到过一些团队，开发者提交代码没有流程，生产分支经常冲突，甚至出现强行覆盖了别人代码的情况，搞的大家差点友尽。开发者之间分支协作是否顺畅，决定着他们是否能成为朋友。小团队尚且如此，协作人数达到十几或者几十人呢，多人共同开发一个模块，这时候就需要约定一些大家都遵守的协作规则了。对此，业界总结了不少协同的经验，常见的有三种：Git-Flow、Github-Flow、Gitlab-Flow，每种模式有自己适合的场景：例如大型项目交付周期长，参与人数多，需要避免不同环境下的代码互相干扰，这种情况下选择复杂的Git-Flow能够更完整地支撑；而对于以DevOps快速迭代的团队来说，在开发得足够快的时候，Master 和 Develop 两个分支可能经常都是一样的，而开发过程也会因为过多的分支而变得复杂。如果不小心切换错了工作分支，回滚又是另一件麻烦事了。这种情况下选择github或gitlab的模式会更加轻量一些。但无论 Github 模式还是 Gitlab 模式，仍然需要创建新的仓库或者临时的分支，这些都将成为资产负债。那么有没有一种方式，不需要创建库，甚至连临时分支都不用创建呢？这样管理成本最低，仓库也更干净。在这样的思路下，云效Codeup支持了一种新的Git协同工作流——推送评审模式，也称为 Agit-Flow。使用推送评审模式，当你接到开发需求时，无需新建派生库和feature或bugfix这类临时分支了。只需要在本地对目标分支执行git push，就可以在云端自动创建一个合并请求，发起入库预评审。结合自动化的检查能力，针对每次推送都可以快速扫描和反馈，帮你定位问题并快速修复。持续的推送可以继续更新合并请求，直到你的功能开发完成了，该跑的自动化检测和评审也通过了，就可以将代码正式合并入库。当然，如果有不同版本或环境并存需求的团队，仍然可以基于主干维护自己稳定的预生产和生产分支，或者不同版本的长期分支。推送评审模式非常适合敏捷的、对代码质量有一定要求的团队。对于技术管理者来说，推送评审模式还有一个附加收益，让仓库权限管理更加简单了。在从前，如果你要和隔壁团队进行共建，或者有一些外包项目需要外部合作时，至少需要给予对方代码库的开发者权限，对方才能进行代码贡献。而现在，你不再需要给对方申请开发者权限了，更不需要给予新建派生库的权限，只需要让他能够查看仓库就可以了，他们就可以通过推送评审模式自由地贡献代码。可读即可贡献，合作管理更简单。我曾经遇到一个朋友，他们公司推行内源开放的文化，代码库对公司同事们开放可读，鼓励团队间代码共享，而他和他的一个兄弟部门合作比较密切。为了更好地联调配合，他抽空了解对方团队的代码逻辑，在阅读中他偶然发现对方引用了一个最近报出高风险的依赖包，于是他直接上手改了代码，通过推送评审模式发起了一个修改的请求，对方立即收到了钉钉通知，快速确认了改动进行了合并。整个过程10分钟内搞定，非常高效地将风险扼杀在了摇篮里。总结最后，请允许我总结一下：在代码评审的协作场景中，云效支持了开箱即用的自动化代码检测服务，配合评审视图的体验改进，合并规则的灵活定制与消息通知的集成，让评审协作更高效、代码质量有保障。在分支协作的场景中，云效的推送评审模式让我们不再需要维护复杂的临时分支，推送即评审，让开发更沉浸，合作更轻松。在我看来，一个靠谱的代码管理平台不仅仅是托管代码，而是能够帮助你将代码变得更好，并且更高效地交付出去。所以，云效Codeup始终在围绕如下三方面努力，为大家打造一个真正好用的代码管理平台。1、安全：安全是基础，打牢基础，我们提供了完备的安全能力。2、协同：协同是引擎，强化引擎，我们改进了协作的高频场景。3、开放：开放是导航，拓展边界，我们拥抱外界丰富的连接。如果你对云效代码管理 Codeup 感兴趣，欢迎前往：codeup.aliyun.com 免费体验。云效研发效能实验室5大场景体验:（1）高效敏捷开发体验；（2）多项目规范轻松落地；（3）代码质量提升小妙招；（4）自动化部署2048小游戏；（5）应用交付扫雷大作战点击前往，完成任一场景体验即可领奖。2000份礼品，100%拿奖！
前面我的同事在分享的时候，指出目前软件研发的最大问题不是效率，而是研发资源的浪费。可能产品经理半天写的需求，开发要埋头苦干三个月。如果错误的选择了一个对业务发展无益的需求，会带着大家往错误的方向越跑越远。那么什么是正确的需求呢？我们认为对于业务发展有帮助、贡献度高的需求视为有价值的需求即正确的需求，而基于有价值需求的不断演进，才会让我们的业务发展越来越好，产品越做越强。今天我想和大家分享的就是云效项目协作在这个新课题上的探索：从敏捷协作到价值交付，从追求效率到追求价值。首先，为新老朋友简单介绍一下云效项目协作这款产品。云效项目协作是面向企业级的研发协作平台，提供了项目、需求、迭代、质量等多个维度的协同管理以及相关的项目度量能力。过去一年，我们落地了敏捷研发以及规模化项目管理的协作场景。为了连接各个角色，让大家围绕价值，顺畅、高效地进行协作，我们继续在多团队分层协作场景中进行探索，帮助团队朝更有益于业务发展的方向前进。为了让分享更场景化，我们从一个需求的交付作为切入点，看看在它的整个生命周期中，价值交付是如何影响到每个流程步骤、每个参与人员的。一个需求从它的诞生到完结，往往会经过很长的流程步骤，经手过很多人。我们从其中选取了三个重要的角色：业务、产品经理、开发经理，来看看他们在需求交付过程中都经历了什么困难。业务同学首先我们聚焦到业务同学萧峰，看看他的工作中遇到了什么问题。萧峰在这个月有一个重要的运营活动要上线。需求上个月已经提给了产品，到了月中跟踪进度的时候发现产品虽然做了排期，但是开发因为种种原因没有做。运营活动是肯定要如期上线的，这个时候萧峰就要紧急拉会，还要找各方协调资源。本来需求在前期协调资源是可以很顺畅的交付，现在变得困难重重。这种情况萧峰不是第一次遇到了，很多次的重要运营活动都上演了类似的场景。萧峰很苦恼，需求明明对业务这么重要，怎么还是总交付不及时呢？为了解决萧峰的问题，云效项目协作提供了便捷、有效的交付进度追踪能力。首先我们去解决萧峰获取进度信息不便捷的问题。云效项目协作Projex可以显性化展示需求的交付进度。萧峰可以很快的看到需求已经完成了哪些阶段、当前处理什么阶段、以及后续还要经过什么阶段才可以进行交付。同时，他还可以同时查看需求在每个阶段的停留时长。如果需求在某个阶段停留时间过长，可以配合规则进行自动通知。让萧峰可以很快的发现并看到交付卡点在哪里，及时识别风险并处理，充分保证需求及时交付。解决了进度信息获取不便捷的问题，还要解决进度同步不及时的问题。萧峰经常会遇到业务需求和交付需求之间状态不同步，带来跟进上的问题。为了解决这个问题，云效项目协作提供了进度自动更新的能力。当一个研发任务进入到开发中，业务需求也会同步进入到开发中，这样萧峰再也不用费心去一个个查看支撑的事项状态，在业务需求中看到的就是真实的进度信息。我们来看看业务人员萧峰，他在使用云效前后工作上有什么改进：● 从“原来的需求提完处于失联状态，交付到了什么阶段全靠问人”到”需求页面显性化展示进度，无需到处求人”● 从“风险信息总是滞后，最后影响交付。”到“需求阶段停留自动计时，及时识别风险。”● 从“进度全靠手动维护，经常更新不及时”到“系统自动更新进度，再也不费心同步”。云效项目协作让业务人员萧峰跟进需求更及时。产品经理我们继续下一个角色：产品经理小宝，看看她在工作中遇到了什么问题。这是某天下班前，小宝收到的工作消息。业务人员萧峰提了个运营活动需求，要下个月交付。接着她对接的开发经理，要下个月进行性能改造，因为不少用户反馈页面响应慢。再接着她的老板提了个目标规划需求，要尽快交付。这个时候的小宝，一个头两个大。谁都认为自己的需求很重要，但是一定要有个先后顺序。毕竟开发人力只有这么多。这种情况也不是小宝第一次遇到了，她一直都在苦恼，需求方这么多，谁提需求都是重要且紧急，那怎么排才对业务发展更好并能够达成团队共识呢？为了解决小宝的问题，云效项目协作提供了有依据的需求排序能力，让需求可以根据价值进行交付排序。云效引入了主题的概念，散点的需求可以聚合到共同的主题内，主题有明确的业务目标和里程碑节点，并可进行价值评估。小宝只需要让需求方确定业务目标影响，让开发评估成本。大家可以基于目标影响和成本进行讨论，达成共识后落入系统，主题的价值分数就会自动呈现。哪些事情重要需要先做可以很快达成共识，小宝只需要按照主题进行需求优先级排序就可以。我们来看看产品经理小宝，她在使用云效前后工作上有什么改进：● 从原来的“会开了一轮又一轮，还是说不清楚谁重要”到“说清楚价值，谁先做自然而然呈现出来”。● 从“原来的单个需求单个排，排完一轮又一轮”到“基于主题进行需求优先级排序。会开少了，交付规划却更加清晰明了。”云效项目协作让产品经理小宝更好地排需求。开发经理我们接下来看最后一个角色：开发经理虚竹，看看在他的工作中遇到了什么困难。某天和虚竹一直合作的业务同学，在群里突然反馈，开发团队的支持度不够，客户投诉了。老板为了能够让团队之间顺畅的合作，让他和业务对齐，看看问题出在哪里。这是虚竹在他的工作中时不时出现的场景。虚竹很纳闷，明明团队里的小伙伴每天都加班加点，怎么会说支持度不够呢？为了解决虚竹的问题，云效项目协作提供了主题角度的投入统计，开发投入在哪里一目了然。首先对于虚竹团队里的开发小伙伴，云效项目协作提供了单个需求溯源能力，可溯源至主题看交付的价值。让开发同学不再只低头做事，也可以抬头看业务。同时对于虚竹的整个团队，云效项目协作提供了基于产品主题的统计能力。通过统计可以看出虚竹团队投入在什么主题上、每个主题的交付效率和趋势都一目了然。让开发团队和业务、产品团队在同一个维度对话。我们来看看开发经理虚竹，他在使用云效前后工作上有什么改进：● 从“接了一个又一个散点需求，团队的开发忙个不停。到年终谁也说不清自己做了什么业务贡献”到● “单点的需求可溯源，团队的投入可被度量”。云效项目协作让虚竹团队的投入看得见。总结至此，我们分别聊了三个重要角色在工作中遇到的困难和云效项目协作在产品能力上的支持。其实每个角色在协作过程中，都有角色特有的愿景：● 萧峰希望“如果需求已经承诺了交付时间，就请如期交付”；● 小宝希望“我选择的需求就是对业务有价值的”● 虚竹希望“我的团队投入对业务有益，且可以被大家看见”云效项目协作帮助他们实现了愿景。总结下来，云效项目协作的价值交付，其实就是在做三件事：第一件事——让需求选得对：支持产品主题价值评估，让价值不再停留在每个人的脑海中，落在系统中形成共识；围绕价值进行需求排序，永远先做重要的事。第二件事——让进度追得到：支持显性化展示进度，不再需要到处问人；支持事项进度的自动更新，不再需要手动维护。最后一件事——让投入看得见：通过业务视角进行交付统计，支撑多少业务价值的落地一目了然。云效的价值交付希望帮助千千万万个企业中的业务同学、产品同学、开发同学做有价值的事儿。云效在协作领域的探索从未止步：从追求效率到追求效能，从面向流程到面向价值，打破职能边界，联通所有角色，让所有人都围绕价值协作。云效项目协作，期待与你的相遇。以上云效项目协作能力正在内测中，点击可申请体验。云效研发效能实验室，有奖体验本次研发效能实验室，提供了5大场景供大家体验:1、高效敏捷开发体验亮点：自动化规则自动更新任务状态、迭代工时管理和容量预估、全面的迭代数据追踪。2、多项目规范轻松落地亮点：低成本实现项目规范下发和同步，贴合业务场景自定义项目规范。3、代码质量提升小妙招亮点：特色推送评审模式+自动化代码检测，降低分支管理成本的同时，有效提升代码质量。4、自动化部署2048小游戏亮点：流水线可视化编排，无缝对接阿里云ECS，轻松实现自动化部署。5、应用交付扫雷大作战亮点：以应用为中心，一个平台，聚合研发资产和流程，搞定从部署架构、环境管理、部署发布等应用全生命周期管理。2000份礼品，完成任一场景体验即可领奖体验直达链接：https://developer.aliyun.com/adc/series/activity/yanfaxiaoneng
作者：张燎原，阿里云云效 产品负责人这几年，云原生、Web3.0、元宇宙等技术的出现和应用，正在深刻地改变着我们这个世界。以数字技术应用为主线的数字化转型是此次人类文明变革的核心动力。在这一变革过程中，软件研发模式的发展起到了重至关重要的作用。从早期瀑布式、精益敏捷、DevOps，再到BizDevOps，其实背后一直在解决的是效能的问题。效能公式# 我们常常聊效能，但研发效能对于不同的人来说，有着不同的定义。对于处在研发一线的个人来说，效能就是提升自己的工作效率，提升工作的幸福感；而对于企业经营者来说，效能就是在不确定性的环境下，确定性地获得最大的商业成功。因此，提升效能，就是让每个人能够高效、专注的工作，工作更有成就感；提升效能，就是让一群人干成一件值得骄傲的事。我们之前定义过，研发效能就是组织持续、顺畅、高质量交付有效价值的能力。从提升效能的角度，研发效能就是提升个体和协同效率，最大化价值。将这个三个变量组合在一起，形成的效能公式就是：个体效率 x 协同效率 x 价值 = 研发效能个体效率对于个人而言，个人的工作效率其实是最影响幸福感的。事情做不好，很大部分原因是，事情理不清、理不顺。老师通过看一个学生的课桌和书包，基本就可以判断这个学生的学习成绩好不好了。桌面干不干净、书本整不整齐、教材和教辅分类是否清楚、考卷有没有分门别类整理等，这些都直接影响着学习的效率。所谓“学霸两支笔，学渣文具多”，如果绝大多数时间和专注力花在找书本找文具上，学习自然是好不了的。另一个影响的效率的重要因素，是那些高频且低效或易于出错的工作。简单重复性强的工作，引入自动化的手段就可以解决。高危操作，出错和返工的成本都极高。将这些问题，交给工具来完成，可以极大地减少由于人为操作导致的问题。所以，我们希望在日常工作中，事情能够有条理的按部就班，要的东西找得到，看得见。重复繁琐的事情，让工具代替手工，更轻松地做，省心、安心、放心。我简单总结，就是三个关键词：找得到、看得见、轻松做。今年，云效分别升级了全站搜索、个人工作台、代码合并、智能测试和应用发布等能力，旨在让：零散信息找得到：通过个人工作台，我们可以将自己关心的工作内容展现在一个页里，“我的项目、我的任务、我的提交、我的发布”，个人工作台就是自己的专属线上办公桌。像整理自己桌面一样整理好自己的工作台，让任务轻松触达；同时，通过全站搜索能力，无论是需求、任务、缺陷、代码、应用、变更等等，都能通过 CMD + K 找到。**任务、进度看得见**：每个人对自己关心的任务、关心的进展，都能轻松地看见。就像观测地铁到站表一样，非常清晰地知道当前任务经过了哪些阶段，当前处在什么阶段，到结束，还需完成哪些阶段。代码提交轻松合：开发者有大量的代码合并和评审的场景，通过辅于自动化的检测能力，帮助开发者在代码合并的时候，轻松判断合并条件，有针对性地进行评审，放心轻松地合并代码。让代码合并省心。回归测试轻松测：测试工作在软件研发过程中，承担着非常重要的质量守护工作，测试工作从写case、准备环境、准备数据...，琐碎而重复，对于这样的工作，我们建议这样的工作交给工具来做，云效除了接口测试、UI测试这些传统的测试工具之外，推出智能流量回放测试。采用智能流量回放测试，可以自动生成测试用例，自动生成测试数据，自动Mock，大幅节省回归测试的成本。让质量内建安心。应用上线轻松发：软件的发布在云研发时代是一个高频操作，同时也是高危操作。云效应用发布平台AppStack，推出面向云原生的应用发布能力，将资源、流程和工具以应用为核心组织在一起，从应用的创建、代码变更、部署发布整个流程固化下来，减少过程中由于人为操作不当而引起一系列问题。同时，部署是最后的临门一脚，辅于发布过程中的可观测能力和部署模式的支持，有效降低发布过程中的风险，应用的发布上线不再熬夜加班。让应用发布放心。只要善于发现，可提升、改进的机会还有很多。不要低估持续不懈地优化和改变，进步的力量，始于每一点微小的改变。协同效率如果说个体效率的提升，影响的是工作幸福感的话，那么协同效率的提升反映的就是组织的成熟度和活力。软件研发是典型的集体性创造活动。人多了，就会有分工，分工有很多好处，亚当·斯密最早提出了分工理论，通过比较优势，分工可以提高效率。但随着组织的发展，职能分工带来最直接的问题就是：效率竖井。关于效率竖井，我们以前讲过很多次。不同的职能分工，职能间的关注点不同，优先级不一致，经常出现扯皮的现象。同时，在整个交付过程中，出现阻塞、等待、返工的情况。彼此沟通过程中，概念不一致，鸡同鸭讲，聊不到一块儿。这样的后果是，每个团队看上去，繁忙而高效，而整体却效率低下。协同的目标，就是让一群人确定性地共同完成一件大事。整个协同应该是一条通路，通是关键。在DevOps中，打破Dev和Ops的墙是为了通，在BizDevOps中，打通Biz和DevOps的墙，也是为了通。这里我把它归纳为两个关键词：连接和透明通过一个需求，与应用的变更建立关联，通过一个需求，与代码合并请求建立关联。双向互联互通，基于统一的数据模型，将这些核心作业对象关联起来，形成一张价值网，这样就建立起来了从协作到工程的完整链路。连接的意义，远大于在研发流程中，将工具简单的拼装在一起。有了核心工作对象的关联，就像接通了整个研发协同系统的血液循环，活了过来，整个系统也就具有了生命力。连接建立了基础，透明化就不再话下。这样，整体的工作进展，从需求、代码、发布完全打通，工作进展更准确、透明。迭代进展能够及时、准确地看到；工作安排是否合理，通过工作负载也能展露无疑。有了连接做为基础，数据在各环节就能共享，任务和进展可以轻松看得见，效能现状也能轻松看得见。一群人，安排了哪些活、在哪一天，工作量是否过大等等。对于管理者而言，效能现状也能做到胸有成竹，团队效能有没有“病”，要不要“吃药”，有了数据的支撑，就能做到对症下药了。同时，通过关系和信息的配置，将流程固化在工具上。让过程管理不再局限于纸面文章，而是可运行、可重复、可推广。然而，无论是提升个体效率，还是协同效率。在软件研发工作中最大的问题，其实是机会的浪费。价值选择比努力重要。资源这么多，只能选择最有价值的事情来干。如果说连接是血液循环系统的话，那么价值就是这个系统支撑的魂。但实际的工作中，往往容易丢了“魂”。丢了“魂”的工作是怎么样的呢？是工作说不清楚价值；是需求很多，但不知道哪个更重要；是我的工作和老板关心的工作不一致；是需求层层分解、任任层层转交，导致信息严重失实。人就那么多，时间也很有限，选择一件对的事情，并且做好分解和传递很重要。所以，我认为做好价值最大化的两个关键因素是：选择和传递。关于选择，收益和成本是最简单的两个变量，通过收益除于成本就可以简单得到一个基础投资收益得分，基于此做为选择需求的参考。一定会有朋友说，价值模型有很多，单纯靠这两个变量是否过于简单。其实，从本质上讲，无论多么复杂的价值模型，背后的底层逻辑都是收益和成本。有了这两个简单的变量，争论便有了基础，而不是看谁嗓门大、关系亲疏、职级高低来决定做哪个需求。这就很有意义，让价值的争论发生在越早越好。同时，有了评估选择的基础，我们就可以做到：以终为始（在开始的时候，就以最终想达成的结果来进行评判选择）和量出而入（在排入需求的时候，就以输出的时候为标准，无论是质，还是量）。从收到一个前线的原始需求，转化为一个产品主题，再逐层分解，直到开发任务，这是整个价值传递的过程。研发的整个流程，其实就是价值流，价值流上的各环节是增值活动。这样，整个价值链上的每个事情都是有价值的，每个事情也都能说明价值。同时，对于业务、产品或技术来说，用一套话语体系说话。从原始输入，到产品需求，再到技术任务，云效通过关联所有的核心对象，让事事有着落，件件能溯源。写到最后通过让事情找得到、看得见、轻松做，提升工作的幸福感，提升个体效率。通过连接和透明化，建立彼此协作的桥梁和信任，提升协同效率。通过价值有效选择和传递，最大化价值。整体共同作用，提升研发效能。基于这个逻辑，让我们从面向流程到面向价值进化，从提升效率到提升效能进化。当然，云效也无法兼顾到研发活动的方方面面，我们愿意和我们的伙伴和用户一起努力，做一点点改变。进化，其实就是每一点点进步。感谢我的同事们努力的工作，让进步一点点发生。最后，欢迎大家对我们的产品提出更多的想法和建议。云效研发效能实验室，有奖体验5大场景体验:（1）高效敏捷开发体验；（2）多项目规范轻松落地；（3）代码质量提升小妙招；（4）自动化部署2048小游戏；（5）应用交付扫雷大作战点击这里，完成任一场景体验即可领奖。2000份礼品，100%拿奖！
点此申请体验
12月22-23日，一年一度的研发效能峰会历时2天顺利闭幕，吸引了大几十万的研发管理者和开发者的观看。和往届峰会一样，今年的峰会内容也是非常丰富，涵盖了从研发协作、交付到度量的研发全流程内容。不少的小伙伴在直播期间，一直问我们，有没有回放啊，嘉宾的PPT是否可以下载。这不，小编趁热给大家奉上咯。之前没来得及看的小伙伴，也可以享用哟！5大专场直播回放1、主论坛精彩看点：● 产学研媒联袂首发必致（BizDevOps）白皮书，助力企业打造高绩效组织● 云效BizDevOps产研数字化平台焕新升级● 信通院、招商银行、南京大学等组织分享最新研究成果与实践案例2、云效产品进化专场精彩看点● 项目协作如何打破业务、产研边界，让团队聚焦目标高效协作● 代码管理如何借助新的评审和分支模式，让团队高效协同● 应用交付如何借助工具加速上云的最后一公里、沉淀研发流程● 如何基于全链路的度量数据体系、让研发过程被看见、让团队工作更高效3、数字化转型专场精彩看点● 系统掌握数字化组织构建方法，助力业务实现关键突破● 掌握IT团队提升业务认知的5个秘诀● 学习数字化时代组装式应用交付的方法与实践● 深度了解富滇银行产研数字化实践案例4、云原生DevOps专场精彩看点● 阿里从VM到云原生混部过程中经历的容器调度典型问题和应对思路● 如何借助 OAM/KubeVela 开源技术，降低企业云原生应用平台构建成本● 如何通过研发流程改进，实现从版本制到持续交付的平滑演进● 如何借助Prometheus构建全栈指标观测体系5、研发效能度量和实践专场精彩看点● 产品制带来的组织膨胀如何破？● 从4KM到SPACE，如何走向人本效能度量？● 效能治标不治本的3大陷阱是什么？● 效能治理的3个闭环和3个建议是什么？● 中金公司、德邦证券、新零售、新制造效能实践有哪些坑和经验可借鉴？5大专场直播回放一键直达白皮书及PPT下载除了视频回放外，我们也在征求嘉宾同意下，将尽可能多的PPT提供给了大家下载。前往峰会下载页面，即可选择你想要的资料。1大白皮书、18份PPT下载，一键直达研发效能实验室除了看视频外，作为每年峰会的保留节目，今年我们也一样为大家提供了研发效能的场景体验活动，旨在帮助大家在实操动手中，感受云上高效交付实践。本次研发效能实验室，提供了5大场景供大家体验1、高效敏捷开发体验亮点：自动化规则自动更新任务状态、迭代工时管理和容量预估、全面的迭代数据追踪2、多项目规范轻松落地亮点：低成本实现项目规范下发和同步，贴合业务场景自定义项目规范3、代码质量提升小妙招亮点：特色推送评审模式+自动化代码检测，降低分支管理成本的同时，有效提升代码质量。4、自动化部署2048小游戏亮点：流水线可视化编排，无缝对接阿里云ECS，轻松实现自动化部署5、应用交付扫雷大作战亮点：以应用为中心，一个平台，聚合研发资产和流程，搞定从部署架构、环境管理、部署发布等应用全生命周期管理2000份礼品，体验完成即可领奖，体验直达
产品、设计、研发，聚在一起会发生什么？今天，云效 Codeup 产研颜值3人组，首次齐聚屏幕前，为大家带来云效 Codeup 10月3大功能更新。干货满满，让我们一起了解一下吧！1、代码检测全新升级，更易用相比老版代码检测，云效新版代码检测做了如下4点增强：（1）支持检测规则查看和自定义组合如下图所示，在【检测方案】中，企业可以根据需要自定义检测方案。云效默认提供【敏感信息检测】、【依赖包漏洞检测】、【源码漏洞检测】、【Java 开发规约检测】、【代码补丁推荐】 5种检测包供企业使用。点击某个具体的检测服务，如源码漏洞检测，还可查看具体的检测规则。每一条规则，支持编辑其严重等级，部分规则还允许自定义检测参数，如通过正则表达式限制检测范围。同时还支持停用不适合的规则或重新启用规则。（2）检测报告轻松查看在一次检测任务执行完成后，点击检测任务，即可完整查看当前分支最近一次成功的全量检测结果和问题列表。（3）支持自定义检测门禁阈值代码检测作为评审的辅助手段，可以减轻代码评审的成本。除了人工评审之外，云效 Codeup 支持将代码检测作为合并代码前的卡点，当检测设置的门禁不通过时，不允许任何人合并代码，避免质量不达标的代码被合并到生产分支。（4）支持查看检测运行日志，快速定位问题云效新版代码检测使用云效 Flow 流水线运行。针对检测运行失败的情况，前往云效流水线产品 Flow 可以方便地查看流水线的错误日志，以便快速定位和解决问题。同时还需注意的是，新版代码检测运行的并发数和运行时长将计入云效流水线资源消耗。每月的资源消耗情况可前往云效流水线 Flow 页面左下角「资源」中进行查看。2、推送评审模式上线，评审更高效推送评审模式，是云效 Codeup 新推出的一种代码协同方式，可以为用户带来全新、高效的代码评审体验：从开发者的角度，发起代码评审不再需要创建新分支，也不必在开发完成后切换至浏览器来创建代码评审，直接执行git push即可一键发起评审；从管理者的角度，可以设置让开发人员向仓库push代码时，不再直接更新分支的代码，而是自动创建代码评审，通过评审的方式，保障代码质量。具体来看，推送评审模式与现有分支模式相比有以下不同：那么如何使用呢？云效 Codeup 工程师3分钟为你详解⬇️3、库首页和文件查改体验优化，更好用为了给开发者带来更优的代码管理体验，本月我们对代码库首页和文件查改这2处进行了体验优化：（1）在库首页体验上：兼容多视角的信息结构：我们将库首页从原先的流式页面，升级为多列灵活布局，满足日常管理、开发贡献等各类角色的使用诉求。大家既能在文件树看文件，又不会错过相关的库基础信息；更高的阅读屏效：经过多轮可用性测试后，新版库首页提供了更为舒适、对开发者友好的信息密度，让视觉重心更聚焦；提供更明确的活跃信息：通过增加代码提交列表，进库即可获知近期的代码活跃情况；图片（2）在文件查改体验上：布局分区更合理：按对象不同，分为全局操作及内容查改两个片区，并按大家使用的高低频率，调整整体操作顺序。图片此外，在变更追溯，问题排查场景，我们正在着手优化Blame、代码块渲染，敬请期待。以上就是云效 Codeup 10月新功能，前往 https://codeup.aliyun.com 即可体验。
提交了问题
2022-10-28
提交了问题
2022-09-28
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-20
阿里云云效代码平台团队匠心出品可能是今年你最值得学习的Git课程9天时间，深入浅出带你了解Git核心原理与使用走近神奇的Git世界有效提升开发和协同效率⬇️点击此处立即报名点击此处立即报名
如今，云原生成为大势所驱，然而，企业想要进行云原生转型，仍然面临着陡峭的学习成本。如果你的企业正在探索云原生转型，但是：● 缺乏云原生研发运维最佳实践指引● 没有一套对开发者友好的云原生应用交付解决方案● 好的研发运维实践无法很好地沉淀以及在团队内推广欢迎加入云效云原生持续交付解决方案客户共创计划，我们将有专业的解决方案架构师与您一起，梳理企业现有难题，带领企业逐步落地云原生持续交付。本次共创不产生任何额外费用，旨在与客户一起，找到痛点，打磨方案，并将方案落地到云效产品中。参与共创，您将有机会一起定义云效下一代云原生持续交付产品。立即报名点这里本次共创指导专家张裕，阿里云云效高级解决方案架构师、阿里巴巴研发效能三板斧培训讲师。拥有15年开发、测试、运维经验，辅导多个团队成功落地DevOps。共创需要做什么1、接受专家面对面问题访谈2、推动解决方案在团队的落地3、参与共创期间每周的产品的共创周会企业通过共创可以收获什么1、发现团队问题：阿里云专家将与您面对面问题访谈，梳理企业持续交付现存问题2、找到解决方案：阿里云专家还会与您一起探讨，提供针对性的企业解决方案3、成为云效产品缔造者您的企业场景，将沉淀在阿里云云效产品内，供数十万企业共同使用4、广泛市场宣传机会成功完成产品共创的企业，将作为云效的标杆案例，在云栖大会、阿里巴巴研发效能峰会等更大舞台上做分享成为共创企业有哪些要求● 企业所在地：杭州● 企业无专职运维或专职运维不超过2人● 企业的研发人员在100人以内● 企业有使用阿里云ACK/ASK或者在ECS上自建K8S● 企业在某个细分行业有一定知名度立即报名如果您是企业的技术主管、架构师或负责团队的技术选型您所在企业满足上述要求，欢迎扫码报名，我们将在1周内与您联系点我报名
编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。本文作者：何勉，阿里云云效资深技术专家谈到DevOps，就必须从敏捷和精益开发说起。DevOps在它们基础上发展而来，借鉴了其中的方法、理念，并发展和完善了它们的实践体系。敏捷软件开发的兴起敏捷软件开发的实践最早出现在上世纪90年代。当时，一批轻量的软件工程方法和框架相继诞生，它们共同的特点是，相对传统软件工程，都遵循演进和迭代的模型，过程更加轻量灵活。其中Scrum和极限编程（ExtremeProgramming）在实践上最为成功，影响最大。它们都是迭代和增量的软件开发框架，区别是Scrum只包含管理实践，而极限编程则同时涵盖工程和管理实践。上世纪90年代，PC软件流行和第四代编程语言的出现，面向对象和设计模式运动的兴起，让小型项目的开发蓬勃发展。同时，互联网应用和开源社区兴起，有别于传统的开发模式不断涌现，优秀个人在程序开发中的作用得到凸显。这些因素都让非传统开发方法有了实验的土壤。其结果是，一方面质量问题层出不穷，这部分促使了源自全面质量管理体系的CMM/CMMI在这一时间的繁荣和推广；另一方面也产生了许多不同于传统方法的有效实践，让业界看到了新的可能。敏捷运动这时已经呼之欲出，它既是对传统的反叛，也是对野蛮生长的规范。2001年2月，17位轻量级软件工程方法的代表人物，齐聚美国犹他州的雪鸟滑雪胜地，其中也包括Scrum和极限编程的几位发明人。在两天的会议之后，发布了后来产生巨大影响的敏捷宣言(参见 http://agilemanifesto.org/)，敏捷宣言陈述了他们共同认可的关于软件的开发方法的理念，同样重要的是他们找到了敏捷这个词来总领这些理念。敏捷概念在2001年出现，可以说适逢其时。当时，一方面传统方法变得越来越臃肿笨重，却没有解决软件危机；另一方面，人类正在进入互联网时代，软件业对响应变化和创新的要求迅速升级，这是更根本的原因，毕竟需求才是行业发展的最好助推剂。敏捷宣言发布后，敏捷成为了一场运动，被迅速地推广和应用。但是，早期的敏捷专注的还是研发交付阶段，站在业务的角度，它的目标是帮助产品和研发团队提升敏捷响应能力，也就是：“更早地交付价值，更灵活地应对变化”。然而，在企业数字化转型的背景之下，IT不仅要保证产品的开发和交付，系统部署和运行同样重要。DevOps继承了敏捷开发的理念，又补上了运维的部分，但DevOps绝不是开发和运维的简单叠加，这个我们后面还会说到。精益产品开发的出现精益思想最早源自生产制造领域，根源于丰田在产品制造中管理和工程实践。1988年《斯隆管理评论》的一篇论文《精益生产系统的胜利》比较了西方的生产方式和丰田生产方式在效率和质量上巨大差距，挑战了规模生产带来效益的神话。从此，精益开始进入西方的视野，逐渐成为现代管理学的重要组成部分。《精益思想》一书将精益定义为：有效组织人类活动的一个新的思维方法，目标是消除浪费，以更多地交付有用的价值。书中进一步总结了精益的5个原则，同时也是精益的5个实施步骤：定义价值：站在用户的视角定义什么是价值，并把它描述为具体产品或服务；识别价值流：识别和映射创造价值的流程步骤，消除不增加用户价值的步骤和活动；让价值持续流动：让用户价值在流程步骤中流动起来，使它们持续、顺畅地流向最终用户；用户价值拉动：由用户价值拉动流动，避免不带来用户价值的浪费；精益求精：不断重复1到4步。追求完美的价值和价值流动，消除过程中所有浪费。在这个抽象层次上，精益思想超越了其诞生的制造业，深刻影响了各个行业，如精益政务、精益医院、精益领导力、精益服务业、精益供应链、精益教育等，这其中也包含产品开发。事实上，主流的敏捷开发方法都直接受到了精益思想的影响，遵循精益的基本原则。与此同时，精益产品开发作为独立的实践体系也快速发展，它聚焦两个方面的目标——价值交付过程和价值本身。第一，关注价值交付过程。其中比较有代表性的是“精益看板方法”，它由David Anderson在2006年左右基于自己的实践发展而来，并在2010年出版的《看板方法》一书中加以系统总结。“看板方法”是精益思想在软件开发中具体应用。它从可视化需求交付端到端的价值流开始，通过系统的实践提升需求的流动效率，并确保流动的过程质量，从而实现端到端的系统改进。“看板方法”为代表的这一类精益实践的本质改变是：从关注资源的使用效率，转变为关注价值的流动效率。这也带动使用者从过去的局部优化转向端到端的全局优化。第二，关注价值本身。其中比较有代表性的是“精益创业”。精益创业的实践最初由Steve Blank基于自己和其他硅谷的创业实践发展而来，Eric Ries在《精益创业》一书中对精益创业的理念和实践，做了系统的总结，并让精益创业的理念迅速普及。精益创业认为创业是一个巨大不确定的过程，其最大的浪费是交付没用的（不能解决用户问题，或带来业务成功）的东西。为此它把价值的探索和发现融入产品交付过程，提出了著名的“开发-测量-学习”循环。循环从关于市场和产品的待检验概念开始。接下来，循环的第一步是开发用以验证这一概念的最小可行产品（MVP，Minimal Viable Product）；第二步：基于最小可行产品收集市场、用户的反馈，并获得测量数据；第三步：用数据验证假设，证实或证伪它们，并加以调整，产生经实证的认知。然后，进入下一循环，持续探索商业模式和产品功能设计。精益创业的影响远超初创公司，事实上“精益创业”一书中把“创业”定义为在不确定的环境下，开创新的业务和产品。而“不确定性”似乎已成为今天IT领域身处环境的共性，也因此，MVP、“开发-测量-学习”循环等理念已成为IT创新领域公认的实践，并且围绕精益创业发展出一套完整的创新实践体系，如精益数据分析、精益客户开发、精益交付设计等。探索和发现有效的价值，并让价值顺畅流动。围绕这两个目标，并遵循精益思想，精益产品开发已经发展成为系统的实践。精益思想对DevOps的影响也非常根本，DevOps三原则就完全遵循了精益思想。DevOps的诞生最初，敏捷和精益社区都还只是关注开发侧的实践和行为，运维并没有成为他们关注的重点。但是，光有系统开发是不够的，开发完的系统必须即时顺利部署，并连续稳定运行才能够实现价值。而传统上，这部分是由运维负责的。从价值的角度，开发加运维才构成相对完整的IT价值链。当然更完整的还应该包含业务，这是后话了，这还不是早期DevOps社区关注的重点。DevOps诞生之初，解决的问题还是开发和运维之间的问题，这是影响IT价值链的最突出问题。在传统的IT组织下，开发团队（Dev）和运维团队（Ops）之间诉求不同——开发团队（尤其是敏捷团队）追求变化，运维团队追求稳定。双方往往存在利益的冲突，比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于IT价值的最大化。2009年，在美国举行的第二届Velocity大会上，来自Flickr公司的John Allspaw和Pauk Hammond发表了一个演讲《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。在这个演讲中，Allspaw和Hammond以角色扮演的方式，生动地表现了开发与运维之间的各种冲突。演讲中出现很多金句，如“It's not my code, it's your machines!”，这深刻反映了Dev和Ops关系的现状。接着，他们又展示了如何通过消除开发团队（Dev）和运维团队（Ops）的壁垒，双方通力合作，借助工具和文化的改变让软件的发布和运维变得持续和高效。这次演讲是DevOps发展历程中的标志性事件。它提出了正确的问题——为了更快交付和实现价值，必须弥合开发和运维之间的鸿沟，并给出了解决方案——为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革。同一年，比利时独立IT咨询师Patrick Debois看到这个演讲，受到启发，组织了第一届DevOpsDays，DevOps正式登上舞台，DevOps的理念开始流行，其相关的工具和实践也快速发展。期间以容器化和自动编排调度为代表的云原生技术的出现也极大加速了这一进程。今天，DevOps已成为企业数字化的核心能力之一，是对IT交付和运行的基本要求。其后，在《凤凰项目》和《DevOps实践指南》两本书中，Gene Kim等人总结了DevOps实施的三步工作法，它们分别是:流动原则：聚焦IT系统的整体价值流，全局优化，保证价值从左（上游）到右（下游）的快速流动。反馈原则：创建从左到右的反馈循环，并缩短反馈周期和放大反馈效果。这样，就可以更快的响应和理解内外部客户，并即时获取改进所需要的知识。持续的实验和学习原则：创建承担风险、持续实验并从错误中学习的文化，在不断的尝试中精进能力，并提高系统的韧性。Kim等人认为，这三步工作法是其他一切DevOps流程、实践的价值和哲学根基，所有DevOps模式都可以从这三个原则派生而来。稍作探究，就能够觉察，DevOps三步工作法是精益原则的翻版。更确切的讲，是精益原则在IT开发和运行上下文中的具体实例。事实上，DevOps的基础部分，体现了精益原则的影响和应用。总结回顾敏捷、精益和DevOps的发展，我们可以得出如下两个结论。第一，DevOps 是敏捷开发实践的自然发展。敏捷开发的目标是“更早地交付价值，更灵活地应对变化”。敏捷运动始于开发侧，但运维侧如果不做改变，就一定会成为瓶颈，最终敏捷的目标还是无法达成。为了让敏捷实践发挥真正的价值，开发运维的联动就势在必行了。第二，DevOps是精益思想应用在IT领域的必然结果。精益产品开发的目标是：“顺畅的交付有效价值”，精益思想则要求端到端的系统优化和持续的改进。而开发和运维是系统的两个重要组成部分，缺一不可。DevOps三原则，正是精益思想在IT开发运维领域的具体实例。最后，从精益思想出发，我们可以看到DevOps的必然发展方向，那就是向业务侧延伸。业务是产品开发和运维的源头，完整的价值流必须从源头开始。这不是预测，而是正在发生的事实，大部分DevOps的实施都已经将业务侧包含在内，成为BizDevOps，只不过DevOps的称谓已经深入人心，我们也将延续DevOps的说法，但缺省情况下，它包含了业务在内。DevOps发展的同时，数字化转型也成为了企业界的共识，大部分企业数字化框架都把DevOps作为最核心的能力之一，DevOps的影响范围也不断扩大，成为力求提升数字化能力的企业必然选择。下一节我们将在数字化转型这一背景下，分析DevOps要解决的根本问题。免费下载《阿里巴巴DevOps实践指南》阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。前往：https://developer.aliyun.com/topic/devops，下载完整版电子书。
6月23日，在2021阿里巴巴研发效能峰会上，由阿里云云效团队20位专家共同撰写的《阿里巴巴DevOps实践指南》（以下简称指南）正式对外发布。本指南是阿里云云效团队对过去十年阿里巴巴DevOps 实践经验的系统总结。指南从DevOps的起源说起，提出了数字化转型下DevOps实施的根本目标；并从阿里巴巴自身实践出发，提出了阿里巴巴DevOps实施的4大价值主张和与之匹配的技术实践体系。最后，指南还总结了阿里巴巴DevOps工具体系大图以及企业DevOps能力成熟度进阶模型。本次指南的发布，旨在向业界输出阿里巴巴集团在DevOps方面的实践经验，促进行业的交流。指南也得到了IBM副合伙人&《银行数字化转型》作者付晓岩、优维科技创始人&CEO王津银、复旦大学计算机科学技术学院副院长彭鑫等人的推荐。目前，《阿里巴巴DevOps实践指南》电子书已开放免费下载，前往https://developer.aliyun.com/topic/devops 即可下载。指南精华内容导读1、从数字化转型看DevOps实施的根本目标数字化转型，是一个系统的变革，DevOps是其中的重要组成部分。数字化时代， IT技术交付和运行的效率，成为决定数字化转型成败的关键，而DevOps要解决的问题正在于此。在数字化转型的背景下，阿里巴巴认为DevOps实施的根本目标是实现业务敏捷。为了实现这个目标，企业需要建设两大能力：第一：持续顺畅高质量地交付有效价值的能力。第二：极致弹性和韧性的系统运行的能力。如何理解DevOps的根本目标和需要建设的两大能力，你可以从指南的第一部分概述找到答案。2、阿里巴巴DevOps实施的4大价值主张和实践体系为了建设上面的2大能力，阿里巴巴提出了DevOps实施的4大价值主张，它们分别是：1）业务驱动的协作模式；2）产品导向的交付模式；3）特性为核心的持续交付；4）应用为核心的运维。这4大价值主张及与之匹配的技术实践也是指南的主体内容，你将从指南的第二章、第三章、第四章的20多篇文章中详细了解到阿里巴巴的DevOps实践。3、阿里巴巴DevOps工具体系DevOps的实施离不开工具的支持。好的工具能够沉淀原则和方法，贯彻正确的价值主张，让DevOps的实施事半功倍。在DevOps实施中，阿里面临诸多挑战。在应对挑战的过程中，阿里逐渐形成了自己特色的DevOps实践，并落地到一套完整的DevOps工具体系中。这套工具体系有如下特点： 一站搞定需求、开发、测试、部署、运维的所有诉求。 松管控、强卡点 可定制、可复用，可扩展你将在指南的第五部分完整了解到阿里巴巴的DevOps工具体系。4、DevOps能力成熟度进阶模型DevOps能力反映的是技术研发响应业务变化的能力。随着组织规模的变大和业务复杂性增长，DevOps能力会变得越来越重要。持续提升DevOps的能力成为技术研发的共同挑战。为了给组织的DevOps能力提升指明方向，并规划清晰的路径。阿里云云效团队在指南内定义了DevOps能力成熟度模型，包含4大类10个能力，希望帮助团队：1）知道我们今天在哪里；2）如何规划提升路径。你将在指南的最后部分详细了解DevOps成熟度模型从L0-L4的5种成熟度进阶。付晓岩、王津银、彭鑫等联合推荐源自阿里巴巴内部的DevOps实践指南，也得到了业界王津银、付晓岩、彭鑫等人的认可和推荐。数字化转型是从社会到企业的整体转型，需要顶层设计和统一规划。数字生态最终是一个高度连接的社会而非一座座割裂的竖井。阿里巴巴DevOps 实践指南说明，一体化的开发和运维要支持的目标正是全链路、全生命周期的业务，这是技术发展的方向，也是数字生态的必然要求。 ——IBM 副合伙人、《银行数字化转型》作者、极客时间《说透数字化转型》专栏作者付晓岩企业的数字化转型必然绕不过DevOps，核心点还是IT如何赋能业务，创造价值。该本指南书体系思路非常清晰，个人理解是从交付态和运行态两个视角去阐述，并完全以应用为视角。交付态也就是今天DevOps 里面提到的核心工程实践：持续交付。持续交付是对过去割裂的IT 组织交付模式的一次革命；运行态，是从连续性运维的角度去探讨，其中又引入了多个不同的最新实践，如智能化运维。难得的是，书中的很多实践都来自于阿里实际，实践完善了理论，理论才可以更好地指导实践。的确是一本难得的实践指南书！ ——优维科技创始人&CEO 王津银DevOps 与云化开发平台的结合实现了软件开发工具平台的一次飞跃，不仅实现了软件开发工具的集成化和流水线化，而且使得基于大数据分析的软件开发质量与效能提升成为可能。《阿里巴巴DevOps 实践指南》的推出为我们了解业界DevOps 和云化开发实践、开展软件开发大数据分析研究工作提供了重要指导。围绕相关话题，学术界和工业界有望开展更多的交流与合作，共同推进软件工程研究与实践的发展。 ——复旦大学计算机科学技术学院副院长、软件学院副院长、教授彭鑫过去10 多年，阿里云在IT 基础设施方面做了非常多的探索和努力，得到了客户和社会的认可。云、大数据、 AI、IoT 等，已成为新一代数字化基础设施。如何让这些基础设施发挥更大作用，推动产业数字化变革，这也 是我们持续努力的方向，DevOps 能力是其中的核心环节之一，希望《阿里巴巴DevOps 实践指南》对你有 所启发，成为你在数字化转型道路上的伙伴。 —— 蒋江伟阿里巴巴合伙人技术创造新商业，技术已成为数字化时代业务创新和发展的核心环节。提升技术的业务响应和交付能力，并保 障系统运行的连续性和稳定性，已成为数字化组织的共同挑战。《阿里巴巴DevOps 实践指南》源自阿里巴巴 多年的一线实践，并做了系统性的沉淀。不管是工程、协作、运维还是工具，希望你能有所收获，并用以指导 实际工作。 —— 刘国华阿里巴巴研究员、混合云平台负责人 从B2B 到淘宝、从跨境电商到本地生活，面对如此丰富、如此大规模的业务交付需求，阿里巴巴在软件交付效 率上一直走在行业的前列。为此，公司从技术文化、技术架构、软件基础设施及平台、以及流程上做了全面和 深入的设计和优化。《阿里巴巴DevOps 实践指南》总结了其中精华的部分，并详细解释了实践背后的思考， 指南的内容主要是由工作在一线的资深工程师撰写，读来体感强烈，推荐给大家。 ——许晓斌阿里巴巴高级技术专家最后，《阿里巴巴DevOps实践指南》电子书已开放免费下载，前往https://developer.aliyun.com/topic/devops 即可下载。
作者简介：张刚，软件工程博士，阿里云云效资深技术专家，ALPD方法学核心成员。读者福利：前往：https://developer.aliyun.com/topic/course/alpd 免费领取阿里爆款架构师课程《DDD高手进阶12讲》（原价98元）。引言领域模型是重要的概念。但是，真正了解并能熟练运用它的人并不多。这实在是殊为可惜的一件事情。软件开发中的许多问题，例如需求难于沟通，软件难以演化，都和领域模型紧密相关。更关键的是，掌握这个概念并不难。通过练习，一个团队只需要一两个小时，就可以习惯领域模型的建模思路，并且开始从中受益。那么，什么是领域模型？如何理解领域模型的本质？为什么领域模型能给软件开发带来巨大帮助？如何表达它，如何应用它？本文将依次展开这些概念。什么是领域模型？首先我们来看什么是领域模型。领域模型定义了领域内的关键的概念以及这些概念之间的关系。为什么要强调“领域内”？是因为模型（或者说概念）只在它所处问题空间中才有意义。这分为两种情况：1）一个概念只在某个特定领域有意义。例如，“应收账款”，就只是在财务领域，更严格的说是会计领域才有意义。2）一个概念必须通过领域限定，才有具体的意义。例如，“轨道”这个概念，它可能是天文学领域的行星运动轨道，也可能是铁路领域的火车轨道，必须得先限定领域，这个概念才有真正的价值。关键信息1：领域模型最重要的是概念，领域模型也被称为概念模型。虽然有人说“领域模型是领域内的概念的可视化表示”，但是， “可视化”并不本质，虽然它也重要。相比较而言，“概念”才是根本。关键信息2：“语言的边界就是思想的边界”—— 一个好的领域模型，必然承载了有用的知识。对一个不熟悉特定领域的人来说，理解概念，往往是进入一个领域最快的方式。例如，小时候的儿歌：太阳大，地球小，地球绕着太阳跑。地球大，月亮小，月亮绕着地球跑。它就可以认为是一种概念模型的表达。在这个模型中，包括了3个概念实体：太阳，地球和月亮。而太阳和地球的关系是地球绕着太阳运动，地球和月亮的关系是月亮绕着地球运动。用一张图画下来就是：这张图其实是UML的对象图，当然即使你不熟悉UML，就是作为线框图，也能很容易理解。同样，在各种业务领域，都有自己的关键概念。这些概念的表达也不一定是图。例如，刚才所讲的会计领域，我们可以使用一张表来表达下列的几个关键概念：会计主体（本方）->对方应收账款货物已经发给对方，但是尚未收到货款应付账款已经收到对方货物，但是尚未支付货款预收账款已经收到对方货款，但是尚未发货预付账款已经支付对方货款，但是尚未收到货物通过这样一张表格，相信即使对会计领域不甚了解对小伙伴，也能快速掌握相关的知识。如果我们更进一步，能够理解到，应收和预付，本质上是本方的债权，而预收和应付，本质上是本方的债务。用一张图表示就是：在这里我们使用了UML类图来表示。对于不熟悉UML的小伙伴，可能需要解释一下三角形箭头的意思，它代表“是一种”，例如，应收账款是一种债权。更严格的，如果一笔应收账款的帐期已经很长，例如5年，那么这种账款有很大概率已经收不回来了，所以需要计提坏账。有一些通用的坏账计提策略，例如：一年以内5%，一到二年20%，二到三年50%，三年以上100%等。所以，面向刚才的应收账款，我们可以用下面的图来表达这样的概念：图是一种视图，它不需要面面俱到。例如，本图中，并没有显示一切和会计科目相关的信息，而只是集中于坏账的计提。其中，我们在应付账款和坏账之间引入了一个新的符号，认识UML的小伙伴知道我们表达的是”应收账款中包括坏账“。图中的帐期、金额等，我们成为“属性”，用于详细的说明应收账款、坏账这些概念还包括哪些内容。由于领域模型本质上传递的是概念，是知识性的信息，所以，对于软件开发的场景来说，把这些知识显式化，能快速对齐不同角色、不同参与方之间的概念，加速沟通，避免误解。领域模型是重要的业务资产领域概念沉淀业务知识，而且非常稳定。一家在某个领域深耕多年的企业，和一个新入行的企业，差别是什么？差距可能是多方面的，但是最大的差距应该是“认知”。——所以我们常常会看到，新入行的企业追赶深耕多年的企业的办法，常常是去成熟的的企业高薪“挖角”。按道理说，挖来的这些人既不能把原公司的客户带来，也不可能把原公司的系统带来，那么本质上他们给新企业带来了什么呢？他们对新公司最大的帮助，是对特定领域的认知。在业务领域，认知非常值钱，而且非常稳定。我们也会看到，一些在某个领域建立了优势的企业，特别是咨询类企业，单靠业务领域的咨询，就能给企业带来客观的收入。如果有良好维护的领域模型，那么领域模型就是这些认知沉淀的最佳位置所在。更重要的是，尽管业务常新，但是领域模型却相当稳定。我们以商品交易为例。我们知道买家、买家、商品、交易这些概念，都是商品交易领域的核心概念。这些概念并不会随着业务的演进发生剧烈的变化，无论是B2C业务，C2C业务，C2M业务，拼团业务还是秒杀业务。不同的业务，体现的只是对这些业务概念的不同组织方式。当然，真正的领域模型要远远比上述概念复杂的多。我们这里只是举一个简单的例子，说明领域概念的稳定性。领域模型的跃迁和生长当然，我们说领域模型稳定，并不是说它一成不变。优秀的领域模型都一定会持续生长，甚至有时候会发生本质的跃迁。一旦一个模型被推翻，我们会认为，我们对某个领域的认知，一定发生了非常本质的跃迁。例如，前述的儿歌“太阳大，地球小，地球绕着太阳跑。地球大，月亮小，月亮绕着地球跑。”并不是一开始就是这样认知的。无论中外，在几百年前，我们都曾经认为，地球是宇宙的中心，太阳、月亮都是绕着地球运行的。那么，这个模型画出来就是下面这个样子：地心说对象图地心说到日心说，是我们宇宙认知到巨大进步，以为日心说模型彻底否定了地心说模型。在软件领域也是这样。我曾经经历过几次领域模型跃迁的场景，每次都伴随这业务认知的巨大进步。当然，在现实生活中，跃迁并不多见。更多的时候都是在原有的模型上稳定发展，逐步增入各种新的概念和各种细节。模型的生长过程，本质上也是业务能力积累的过程。稳定的领域模型带来软件的适应性需求是不稳定性的，而领域模型是稳定的，这启发我们，如果以领域模型为中心去构造软件，那么我们就会构造出很多稳定的积木块。新的需求，就可能通过这些稳定的积木块，通过不同的搭建方式，形成丰富多彩的应用。在这种情况下，我们的软件对于变化的适应力最强，开发成本最低。领域模型存在于哪里用类图表示领域模型UML类图是表达领域模型的非常好的工具，虽然并不存在如何表达领域模型的标准。因为在UML中，“类”并不简单是软件设计中的“类”，它代表的其实是“概念”，所以，把类图用在领域模型的表达上，是非常恰切的。而且，UML已经约定了概念和概念之间的关系，例如：类、属性、关联、关联的多重性、泛化、聚合、组合、依赖等等。对于不熟悉UML的人来说，使用UML也完全没必要有什么心理负担。UML是一个高度灵活的结构，它具有渐近的能力。你没有必要掌握所有复杂的概念才开始工作，根据我的经验，只要一开始能把类（代表概念）、类的属性和它们的关系描述出来，最多再知道多重性怎么表示，就足以应付大多数的场景。有些小伙伴有面向对象的经验，在这里会纠结于要不要对“方法/操作”进行建模。在“领域模型”是一种“业务概念”这个上下文中，方法是完全多余的东西，暂时不需要在这个阶段进行建模。我认为在实现阶段补足它们更合适。在交流和文档中使用领域模型领域模型写在纸上并不是最关键的。作为概念模型，它反映了这个领域的最重要的概念，也构成了表达业务概念的词汇。所以：最好的领域模型，应该时刻存在于团队成员的心中，存在于日常的交流活动中。为了做到这一点，我对自己的团队和辅导过的团队，都有一个要求，这个要求也被成为交流活动中的“统一语言”：任何在需求描述中出现的概念，都必须出现在领域模型中。如果需求描述中存在概念之间的关系，领域模型中也必须有这个关系这个要求看似简单，实际做到会比较困难。特别在刚开始的时候，团队成员可能并不适应这种做法，常常就忘记了这个准则，需要经常纠正。但是一旦习惯，大家会发现，在日常交流活动中，因为所有的概念都已经显式化，误解大大减少，共识更容易达成，导致的后果就是最后团队成员，都会非常自觉的维护“统一语言”的做法。出于同样的原因，编写文档时，使用领域模型作为统一语言也成了一个非常自然的结果。在代码中使用领域模型由于领域模型已经被显式化，所以如果能够在代码中使用领域模型，那么代码就会获得更好的易读性。由于领域模型和代码对应的更加一致，那么在领域模型发生演进时，代码就会变得更容易演进。在这方面，领域驱动设计给出了一组完备的模式，可以帮助架构师和开发人员自然地把领域模型转化为代码。本文中我们并不准备展开这些模式。在此，暂时先请读者们记住下面的结论，后面会有更深入的讨论：代码和问题域之间的表示差距应该尽量缩小，领域模型是连接现实世界和数字世界的最佳桥梁。使用领域模型作为代码中的业务概念的基本表达元素，可以大幅提升代码的易读性，也可以更好的支持业务的演进。领域模型来自哪里领域模型反映了关键的业务认知，但是认知并不会凭空建立。能够一上来就洞悉一切本质的，要么是这个人是天才，要么说明这个领域已经是一个非常成熟的领域，已经无需探索和发现。大多数时候，认知都来自于业务场景的启发。所以，领域模型建立的过程，往往是伴随着需求分析同步产生的。我画了下面这张图，来说明领域模型和业务场景之间的关系：也就是说，领域模型是在业务场景的激励下逐渐完善的。而且，反过来因为对领域的认知更加深刻，领域模型还有助于新的业务场景的发现。探索和发现最好不要一个人独自进行。更多地时候，应该尽量进行集体建模。集体建模不仅仅利于探索和发现，而且它也有助于达成对于关键业务概念的共识。集体建模的最好工具并不是UML的电子化工具，使用白板，在开放空间中的讨论，往往能够收到最好的效果。由于领域模型表达的是概念，所以对于概念及时地分解和抽象，是领域建模的基本功。当然，现实中受过严格的分解和抽象训练的人并不多，特别是很多业务人员往往都缺乏这方面的能力。我在实际工作中，观察到具有面向对象经验的开发人员，经过一定时间的练习，可以很快掌握这方面的技能。所以，如果有一些具有经验的开发人员参与建模，往往可以获得质量更高的模型。常见误区领域模型的概念产生于90年代的面向对象社区。在那个时候，业务变化还不像今天这样频繁，迭代的思想也还没有完全成熟，业务人员和技术人员也没有像今天这样密集的交流，所以，无论是从参考书上，还是实践上，领域模型的概念都难免留下早年做法的影响。其中，有若干误区，在实践中是应该尽量避免的：误区1: 从开发视角进行领域模型的建模常常有技术人员问：“领域模型和ER图有什么关系？” 对这个问题最直接的回答就是：“没有关系”。固然，我肯定知道在有了领域模型之后，设计ER图会更简单，或者对于一个还缺乏领域模型的遗留系统，研究数据库结构可以带来有效的输入，但是它们的立足点是完全不一样的。领域模型一定要从业务视角去看，因为领域模型反映的是业务认知。一旦在领域模型中掺杂了技术的概念，不仅仅是因为它不够纯粹，更重要的是它已经堵死了从业务视角对领域模型进行演进和纠正的机会。因为没有软件背景的业务人员，是不可能去看一个充斥着技术概念的模型的。统一语言无法建立，领域模型带来的价值就已经损失了一大部分。此外，从开发视角进行建模，往往还会忽视业务人员的参与。而实践一再表明，资深的业务人员在领域建模时，往往能提出深入的洞察。所以，从开发视角对领域模型进行建模绝对不可取。误区2: 建立庞大的领域模型当我们说“领域”的时候，并没有限定一个“领域”应该有多大。究竟是“航空”作为一个领域，还是“航空”中的“订票”是一个领域？当你考虑到“领域的核心是认知”，这个答案就变得非常清楚了。领域越大，越不利于建立认知和共识。我们应该这问题域，把大的领域划分为小的领域，然后逐个建立这些小的领域的领域模型。那种整整一面墙的领域模型，往往都是不可取的。 误区3: 重文档，轻交流和共识领域模型的核心在于建立共同的共识，所以，如果只是把领域模型作为一种“制品”，作为某个阶段的“输出”，这是非常不合适的。领域模型需要作为交流工具。“统一语言”是避免该误区的重要方法。误区4: 不把领域模型显式化很多人认为自己是有“认知”的，甚至是有“领域模型”的，但是，如果你问他们模型在哪里，这些要么就是在某个项目曾经有过一些讨论，但是现在已经不知所踪，要么就是虽然文档还在，但是团队的概念表达依旧混乱。没有显式化，没有把领域模型写下来，没有形成团队口口相传的知识，那么这种模型，并不真正存在。除了“统一语言”，我们还有一个非常简便的检验方法，就是看这个团队如何给新人介绍自己的系统。因为领域模型反映了基本的业务概念，是一个非常好的新人培养工具，但凡真正有“领域模型”的组织，是不可能不把领域模型拿出来做介绍的。总结本文我们主要介绍了领域模型的基本概念及重要度，领域模型对于“统一语言”的价值以及领域模型应用的常见误区。总结一下要点：领域模型的本质是概念和认知，它定义了领域内的关键概念以及这些概念之间的关系相对于业务的多变，领域模型相对稳定，优质的领域模型可以低成本的支持业务，领域模型也是统一语言的基础，能有效提升沟通效率领域模型来自于业务滋养，领域模型生长的过程，也是业务认知建立的过程，协作建模是更有效的建模方法在你的团队中，有显式的领域模型和共同的业务认知吗？它在指导日常的交流和开发工作吗？如果还没有，让我们开始吧。课程推荐：《DDD高手进阶12讲》本文内容源自阿里云云效推出的《ALPD云架构师系列——DDD高手进阶12讲》。这是一门阿里内部的爆款课程，获得数千阿里工程师口碑推荐，值得每位开发者反复学习。或PC端前往如下链接获取课程，免费领取阿里爆款架构师课程《DDD高手进阶12讲》（原价98元）https://developer.aliyun.com/topic/course/alpd
1场千人峰会、2门精品课程、2本电子书、20+篇干货文章，2020阿里巴巴研发效能&DevOps干货合集，都在这里了，阿里云云效为你精心盘点。精品课程、电子书、峰会视频PPT合集：ALPD是阿里云云效团队提出的数字化和云原生时代的研发效能提升方法体系，如下图所示，我们将这个方法体系概括为阿里巴巴研发效能三板斧,我们的课程、电子书等内容也将围绕这个方法体系展开。精品课程一、领域驱动设计部分：阿里内部爆款课程、数千阿里工程师推荐：DDD高手进阶12讲二、云原生工程实践部分：首个云原生DevOps课程，抓住云原生技术红利：云原生DevOps 36计2021我们还将推出：《阿里巴巴研发效能三板斧》、《全链路精益协作》、《精益需求分析》更多精品课程。电子书：一、阿里巴巴DevOps实践手册二、阿里云云效助力企业10倍研发效能提升案例集峰会2020阿里巴巴研发效能峰会：阿里年度研发效能盛会，30+视频回放、嘉宾PPT，一键直达同时，2021阿里巴巴研发效能峰会，敬请期待。2020阿里研发效能&DevOps文章合集一、总览ALPD，云原生时代的研发新范式阿里巴巴DevOps文化浅谈数字化时代，阿里巴巴如何构建下一代研发协同工具平台二、敏捷研发篇业务驱动的精益敏捷研发？三、代码与架构篇阿里巴巴自研代码管理平台技术解密CodeReview效率低，试一试智能语法服务阿里巴巴代码缺陷检测探索与实践云原生时代的领域驱动设计（DDD）：从没有银弹说起四、持续交付篇云原生DevOps 5步升级路径阿里巴巴CI/CD规模化落地浅析阿里巴巴测试环境管理实践概述阿里巴巴测试管理开源工具箱：单人开发场景下的测试环境实践阿里巴巴测试管理开源工具箱:云原生下的开发测试一文详解Kubernetes下如何选择合适的发布模式五、解决方案走进云研发时代，阿里云云原生DevOps解决方案正式发布云原生DevOps 5步升级路径云效架构师手把手带你搭建DevOps平台六、案例篇商米DevOps落地实践考拉云原生DevOps大规模落地实践阿里云云效助力企业10倍效能提升案例集欢迎持续锁定云效云原生DevOps社区2021，更多精彩内容，欢迎加入云效云原生DevOps社区
1月15日，云计算情报局第3期，阿里云云效为你揭秘：如何通过新的研发模式和新的DevOps平台，助力企业10倍研发效能提升，并为你剖析考拉和阿里新零售中台研发效能提升案例。 加入钉钉群：32877337或点击 直播预约 立即报名 加入钉钉群：32877337或点击 直播预约 立即报名
本文作者：张刚，阿里云云效资深技术专家，ALPD方法学核心成员。立即学习：https://developer.aliyun.com/topic/course/alpd软件开发的本质困难1986年，软件工程巨匠Frederick Brooks撰写了一篇著名的论文《没有银弹》。他在文章的开篇写道：在未来的10年以内，不存在任何单一的方法和技术，能够10倍以上的提高软件开发的生产力。这个论断在当时就引发了巨大的争议。至今，《没有银弹》仍然是一个被经常拿出来讨论的话题。不过，这篇论文的真正价值远不限于此，继续读下去，就会发现，。停留在是否存在10倍以上生产率的讨论是不够的。真正值得关心的，是Brooks对原因的论断。我把其中的重要观点概括如下：软件开发的困难有两类，一类是本质（Essential）困难，一类是附属性（Accidental）困难。本质困难是和软件的本质紧密联系在一起的，所以这类困难无法通过工具或者语言等加以解决。例如，软件解决的问题是现实世界的问题，如果现实世界的问题本来就是复杂的，那么无论任何工具，都不可能消除这种复杂性。附属性困难是和我们采取的工具或者方法相关的。例如，软件需要被通过某种语言实现，软件需要被编译、被部署，软件可能被实现为缺陷，这些都和具体的实现方法相关。这一类困难，可以通过工具、方法和技术的提升得以改善。本质困难包括软件的复杂性，不可见性、可变更性和符合性（指软件开发还需要遵从诸如法律法规、外部系统等不受主观意志决定的因素）作为一名在软件开发行业工作了20年的架构师，《没有银弹》关于本质困难和附属性困难的论述给了我巨大启发。多年以来，我一直都把“管理本质困难、消除附属困难”作为软件开发活动的座右铭。特别有意思的是，最近我发现，作为一个主要工作在业务系统上的架构师，在云原生渐成趋势的时候，架构师的职责已然发生了改变。而这个变化，恰恰和“管理本质困难、消除附属困难”密切相关。业务架构当然也是架构师的重要职责。业务和技术已经深度融合，业务对响应速度的要求和开发质量的要求越来越高，同时在云原生时代，服务化几乎成为必然选择。而无论是业务响应能力、开发质量和服务化，都和业务规划能力密切相关。这不就是最重要的“管理本质困难”的方面嘛！领域驱动设计，虽然Eric Evans的同名书籍写于2004年，多年以来，在技术社区也有较大影响。但是为什么最近几年热度突然大幅上升，变得特别受关注呢？这是因为，我们的业务终于越变越复杂，到了如果没有恰当的方法，就不能很好的管理的地步——这也恰恰暗合了DDD一书的副标题“软件核心复杂性应对之道“。微服务和云原生在服务方面的划分等，也是关键的助推因素。成为云原生时代的架构师在今天的业务环境下，能更好地利用好云原生基础设施，更好地进行业务规划、高效高质地分析和管理领域模型，用领域模型指导架构设计和开发实践，是云原生时代架构师的重要技能。这次云效和阿里云开发者学院联合推出的《ALPD云架构师系列——领域驱动设计》课程也正是围绕着这个主题展开。ALPD全称Advanced Lean product development，它是阿里云云效团队提出的云原生时代的研发新范式，它整合了技术、工程、协作、创新4类实践，并提供高效解决方案。上面2幅图分别是ALPD方法和支撑体系图，我们希望ALPD及其解决方案可以帮助企业和开发者，实现10倍效能提升——10倍的响应速度，10倍的过程质量，10倍的有效价值交付。在本次课程中，我们将为大家带来 ALPD方法体系中的领域驱动的架构和实践 部分的内容。能通过这一次的对外整理，将知识和经验分享给社区开发者小伙伴，也是非常开心的事情。ALPD云架构师系列课程——DDD高手进阶在课程整理中，我们把课程分成了如下章节：01|领域模型的本质是业务认知02|案例分析：高质量领域模型提升业务灵活性03|高质量领域模型源自持续演进04|案例分析：梳理业务概念，发现领域模型05|从模型到代码：领域驱动设计的构造块06|聚合：保证业务完整性的单元07|领域驱动设计的分层模型和代码组织08|核心域、通用域和支撑域09|基于业务能力和业务场景拆分子域10|守护领域边界，构建自治服务11|限界上下文映射的模式12|使用微服务构建领域资产其中每讲都保持了15分钟左右的篇幅，以聚焦于一个比较内聚的主题。1-4讲，讨论领域模型的一个基础概念，包括什么是领域模型？为什么要关心领域模型?如何进行基本的领域建模？5-7讲，主要关心领域模型为中心的软件实现，具体对应于领域驱动设计的战术模式，例如实体对象、值对象，领域服务、领域事件构造块及聚合、资源库和工厂这些跟业务完整性密切相关的部分。8-12讲，关心领域模型为中心的架构设计，具体对应于领域驱动设计的战略模式，比如说子域、限界上下文、限界上下文映射等方面的话题。最后的12讲，我们把微服务跟领域资产之间的关系也做了讨论，微服务是当前一个重要话题，如果对领域驱动设计关注不足，也会影响到微服务和云原生的实施。在整个课程中，没有晦涩难懂的概念，我更希望能通过简明的案例让学员轻松理解领域驱动设计的核心思想和关键实践。希望你也能通过学习这个课程，可以从本质出发，更好地理解DDD并付诸实际项目实施。点击下方图片或文末链接，加入《云架构师系列课程——DDD架构实战》的学习之路吧！当然，领域建模和领域驱动设计仍然是需要长期刻意练习的技能，课程中的内容也还只是抛砖引玉，在后续的实际工作中希望你能持续应用和提升，不断精进，成为云原生时代的卓越架构师！立即学习：https://developer.aliyun.com/topic/course/alpd
作者：郑云龙，阿里云云效技术专家Kubernetes面向通用场景提供了非常灵活的应用管理和运维方式，而作为云效CI/CD平台的开发同学，在日常和用户交流过程中，我们经常会被用户问到关于发布的问题，比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。今天我们就来聊聊Kubernetes下应用发布方式的选择，每种发布模式适合什么样的场景，以及如何在云效上高效落地。Kubernetes应用首先我们来看看一般情况下Kubernetes是如何管理应用的。 Kubernetes通过声明式的API，并提供了一系列的资源来满足各种各样的应用运维场景：• 从应用的角度我们会关注应用容器（Pod），应用配置（ConfigMap/Secret），应用需要持久化的信息（Volume），应用与应用之间的服务发现（Service），以及如何将应用服务暴露给集群外的用户（Ingress）等。• 从集群运维的角度看，由于应用运行在集群中我们需要控制应用在集群中的权限（ServiceAccount/ClusterRole/Role）使得应用能够以最小所需权限原则在集群中运行，同时运维要管理和配置集群的存储资源(PV/PVC)，同时对于资源有限的情况我们还需要管理和控制应用本身的资源暂用以及配额（quata）等等等。而在实际场景中由于应用使用的框架（Dubbo/Spring Cloud）的不同，应用对外提供的服务场景不同（后端或者前端），不同的应用可能只需要关注其中的一小部分资源比如当你采用了像Spring Cloud或者Dubbo这类自带了服务发现的应用开发框架，你可能并不关心Kubernetes所提供的服务发现能力(Service)，只需要通过Deployment来部署和管理这些应用实例。 又比如说如果你采用了单独的配置管理中心，那ConfigMap/Secret这些可能也不会出现在你的Kubernetes资源清单中。又比如说，如果是一个面向用户前端应用，在应用部署是除了Deployment实例以外，你还要关系如何将这个服务暴露给外部用户，这是就需要相应的Ingress以及Service的资源来描述。同时在单个应用在整个系统中所处的位置不同又会导致我们对于发布的验证方式也会产生差异，比如一个后端微服务的发布，我们可能只需要确保发布过程系统不中断即可，而对于前端应用我们可能希望发布能够现在一小部分用户上进行验证，在线上流量充分测试后，再完成整个版本升级。如上所示，对于应用而言采用的技术架构不同，提供的服务的方式不同，对发布验证方式要求的不同都会导致Kubernetes的使用上产生各种各样的差异，而云效为了能够支持这些不同的差异提供了多种多样的发布模式，接下来我们就来看看云效下常用的这些发布模式，以及他们所适用的场景。Kubernetes发布模式最原生：YAML发布顾名思义，这是我们在使用Kubernetes时最直接的应用部署方式，而在持续交付流水线中我们一般将这些用于描述Kubernetes资源的YAML文件通过Git进行统一版本管理，通过云效CI/CD平台监听代码库的变更事件，并通过流水线将这些YAML变更同步到集群当中。这种方式也被称为GitOps模式。在云效当中，我们除了支持直接同步YAML到Kubernetes集群以外，还扩展了基本的模板能力，你可以通过在YAML文件中定义变量占位符如${IMAGE}，通过流水线运行是通过Docker镜像构建或者阿里云镜像仓库触发器（帮助文档：阿里云镜像仓库触发器触发流水线），动态产生要发布的镜像版本如下所示：YAML发布支持任意资源类型，因此适用于如下场景：1、开发自运维，团队并充分理解和掌握Kubernetes原生的发布策略，希望通过YAML完成应用的升级与发布以及回滚，一般来说应用Git库会包含应用源码，Dockerfile以及部署应用所需的所有YAML文件（在某些情况下，YAML可能是由单独的Git仓库进行管理，以进行细粒度的权限控制）。2、基础设施运维：运维团队通过Git管理集群的所有基础设施配置，并通过流水线完成集群的统一管理以及配置的同步更多详细使用介绍请参考：云效Kubernetes YAML发布**最简单：镜像升级**在和一些云效用户的交流场景中，在也会有用户希望开发团队能够尽可能少的理解Kubernetes相关概念，在这种情况下由专职的运维团队负责完成应用环境的部署和初始化。而开发团队只负责完成代码开发，并通过流水线自动化完成应用镜像构建，并使用该镜像对集群中已有的应用进行升级。开发团队只关心应用的工作负载实例资源。如下图所示，在云效流水线中我们监听应用代码库的变化，并构建出相应的Docker镜像，而发布阶段只需要指定对集群中实例并关联前序任务产生的镜像即可完成应用的升级发布：如上所述，该场景适用于：• 开发和运维分离：运维团队充分理解Kubernetes的原生发布策略，开发团队只负责产出代码以及应用镜像，由运维团队负责集群中应用的实际运维管理。关于如何在云效中使用镜像升级能力，请参考：云效Kubernetes镜像升级过程可控：分批发布在前面两个小结中，我们都强调用户需要充分理解Kubernetes的原生发布策略，Kubernetes原生的发布策略主要是指RollingUpdate模式，用户通过声明升级策略，如maxSurge和maxUnavailable控制Pod的启动策略以及最大不可用Pod数，来确保即使应用发布出现异常的情况，也能保证服务的基本可用。 除此，由于应用启动往往有一定的耗时，如果使用了Kubernetes的服务发现机制，我们还需要配置如liveness以及readiness探针，来避免应用还在启动过程中就有不在计划内的流量进入到正在启动的实例当中。同时整个发布过程是不可逆的，假如认定当前发布出现了异常我们只能通过重新发布的方式来使应用回到可用状态。而在云效的分批发布中，我们以Service为最小发布单元，在发布开始阶段我们将基于新版镜像创建出应用的版本V2，并根据当前应用的副本总数以及分批数量，对新旧两个版本的应用实例分别进行缩容和扩容，来控制实际进入到新版应用的流量比例，从而可以实现小规模的发布验证，在对发布进行充分验证后再逐步完全下线老版应用。同时批次之间支持暂停和手动恢复让用户可以充分对针对发布过程进行控制。该模式适用于：采用Kubernetes原生的服务发现机制，并希望获得相比于原生Kubernetes发布更好过程控制性以及安全性的用户。更多详细使用介绍，请参考帮助文档：云效Kubernetes分批发布外部流量可控：Ingress灰度发布相比于分批发布灰度发布更强调更加可控和安全的线上验证。而灰度发布在Kubernetes中由于应用的部署模式的不同大致分为两种，我们首先来说第一种，基于Ingress的灰度发布，如下所示，我们通过Ingress将集群内的服务暴露给外部用户：在发布过程中我们希望能够通过cookie或者header的方式使得特定的用户或者开发人员，能够在线上对新版本引用进行验证，经过小部分可控的线上流量验证后，我们的发布可靠性更好，如果出现预期外的问题，也可以快速回滚，并且整个灰度验证过程对非灰度用户完全不可感知。在云效流水线的Ingress灰度发布中，我们以Ingress作为发布单元，当触发部署后，将会根据当前Ingress以及其关联的Service/Deployment资源，基于新版镜像创建出V2版本的Service/Deployment。 并通过Nginx Ingress的Annoation完成对流量规则声明，从而确保只有满足特定特征的流量才能进入到V2版本中，当处于灰度状态时，流水线将会等待人工验证，以触发发布或者或者回滚操作。关于如何在云效流水线中使用灰度发布请参考帮助文档：云效Nginx Ingress灰度发布该模式适用于：采用Ingress对外暴露应用服务，并且希望能够通过灰度的方式对发布进行验证内部流量可控：Istio/ASM灰度发布而在微服务的场景中，并不是所有的服务都需要直接暴露给外部用户，如下所示：当采用微服务架构，我们大部分的后端服务是只暴露与集群内，微服务之间通过Kubernetes Service进行相互访问，在这种情况下，当采用灰度发布模式时，我们需要在Service级别进行流量控制，已确保指定的流量才进入到灰度的链路而不对正常用户产生影响。不过由于Kubernetes原生在Service级别并不支持任何的流量控制规则，因此我们需要在集群中部署Istio或者采用阿里云ServiceMesh来对服务之间的流量进行细粒度的控制。如下图所示，当使用Kubernetes蓝绿发布模式时，可以设置灰度流量规则，从而只有当请求中包含指定的Cookie配置的请求转发到灰度版本当中：该模式适用于：采用Istio或者阿里云ServiceMesh的Kubernetes用户，并且希望能够通过灰度的方式对发布进行验证。更多使用介绍请参考：云效Kubernetes灰度发布小结在本文中，我们主要介绍了Kubernetes实际中的各种发布模式以及相关的适用场景，希望能够帮助用户快速找到适合自己的发布模式，当然如果你还有更多更好的交付实践，也可以在留言中进行分享。如果你对云效流水线感兴趣，前往 云效流水线 即可免费使用。
2020年10月21日，阿里云云效DevOps平台联合云原生应用平台共同举办“阿里云云原生DevOps解决方案重磅发布”云端发布会，正式发布基于阿里巴巴最佳研发实践的云原生DevOps解决方案及典型应用场景。 登录“阿里云云原生DevOps解决方案重磅发布”官网：https://yqh.aliyun.com/live/devops）获取发布会视频回放、PPT、体验云原生DevOps场景、免费领取23722元云效企业级一站式DevOps套餐。 开发者在云研发时代遇到的挑战 阿里云智能高级解决方案架构师张裕在分享中指出，我们正处在一个云研发的时代，并总结了云研发时代的三个“要求”。第一，IT基础设施需要可靠、低成本、高弹性；第二，向用户提供的服务需要稳定、安全、高性能；第三，软件交付要持续、快速、高质量、低风险。 所谓“理想很丰满，现实很骨感”。与上述“理想状态”恰恰相反的是，在云研发时代，软件开发者遇到了诸多挑战。 第一个挑战，IT基础设施成本越来越高。在企业初创时期，可能只需要几台服务器就可以满足业务需求，但是随着业务发展，用户规模不断扩大，可能需要几排机柜、甚至一个机房才能满足需求。而且IT基础设施成本的增长的速率往往是大于业务规模增长的，这就会让开发者觉得基础设施的成本越来越高。 第二个挑战，“发不了，老出错，时间长”。在上图中显示了A、B两款应用近半年的发布情况，其中纵轴代表发布一次所使用的时长，横轴代表发布日期，每一个绿点代表一次成功发布，红点代表失败的发布。我们可以看到，A应用半年发布了13次，但是有7次是HotFix的发布，即带紧急Bug修复的发布，而且发布时长差别特别大，从几分钟到几天都有。B应用的发布很频繁，但是发布成功率不到30%，每次发布时长都超过24小时，而且有的时候连续多天没有发布。 第三个挑战，用于新功能开发的时间越来越少。在软件研发初期，我们几乎所有的人力都可以用于软件研发，但是随着应用功能的丰富，越来越多的人力用于已有功能的维护，几乎没有时间来进行新功能开发。 云研发时代需要基于云原生的持续交付实践 那么，如何迈向云研发时代呢？我们需要基于云原生的持续交付实践，包含云原生基础设施、端到端的持续交付流水线、高质量守护和低成本、高效率的服务治理体系四个方面。 在上世纪五六十年代，标准化集装箱的采用，由此建立起一整套标准化的运输体系，有效降低了货运成本，并最终促进了经济全球化。而云原生技术中的“容器”和“集装箱”有着异曲同工之妙。张裕介绍说，云原生基础设施具备“不可变”和“标准化”两个特点，通过“不可变” 消除不一致带来的不确定性，减少不一致的风险，从而降低维护成本；通过“标准化” 简化部署，降低环境维护成本，同时降低工具链开发和学习成本。 一条标准的“端到端的持续交付流水线”一般包含需求分析、代码提交、构建、集成验证、预发、上线等环节，并且需要具备可描述、可观测、自动化三个特性。 有了“云原生基础设施”和“端到端的持续交付流水线”之后，我们还需要“高质量的质量守护”来提升软件发布质量。质量守护是开发、测试、运维所有人的事，其实大家都是在“一条船上”，只有所有人同舟共济，共同努力，才能保障软件的高质量交付。 最后，我们需要一个低成本、高效率的服务治理体系。当一款微服务发布后，服务平台可以提供一系列服务治理体系，包括网关、服务监控、自动扩缩容等。这样开发者就可以只专注于开发代码，而不用考虑太多服务治理相关的事情。 阿里云云原生DevOps解决方案重磅发布 为帮助更多企业和开发者高质量、低成本地享受技术升级带来的研发福利，云效联合云原生团队打造了一站式云原生DevOps解决方案，无论是通用K8s场景、Spring Cloud/Dubbo微服务场景、还是轻量级的函数计算场景，云效DevOps都能从容应对。 如上图所示，左上方是“云效看板”，产品经理可以利用“云效看板”将需求管理起来，当“需求”经过澄清和规划之后，拆分成“任务”分配到某个团队或某个开发者进行“任务执行”。开发过程中，开发者借助云效代码管理平台，创建特性变更分支。当代码被提交后，会触发特性分支监听，在这期间，云效会自动进行代码扫描、代码评审和安全扫描等。代码开发完后，开发者可以通过云效流水线，进行编译构建、开发验证、上线审核、生产发布等环节。流水线会依赖多个阿里云提供的服务，比如在编译时会依赖“镜像服务”，在开发验证、生产发布等环节会依赖ACK集群服务而当应用正式上线之后，又会依赖微服务治理服务，包括配置中心、服务监控、容量调整等等。而所有这些信息，最后会通过钉钉等方式反馈给开发者。当出现问题时，会以“缺陷”的形式体现在云效看板中。 总结来说，云效的云原生持续交付解决方案包含四个方面：第一，云原生基础设施，支持阿里云容器服务ACK、函数计算（FC）、Serverless引擎（SAE）等；第二，通过云效看板、代码管理平台、流水线实现了端到端的持续交付流水线；第三，通过云效代码管理的自动化扫描和云效流水线的检测和验证实现高质量的质量守护；第四，阿里云的微服务治理实现了低成本、高质量的服务治理体系。 云效云原生DevOps解决方案典型应用场景 云效云原生DevOps解决方案包含三个典型应用场景：函数计算持续交付场景 、微服务持续交付场景、通用云原生持续交付场景。 “云效+函数计算”的持续交付方式比较适合开发者规模较小的初创团队。因为他们的业务往往处于快速验证和发展阶段，希望业务能快速上线、快速更新、无需关心业务之外的工作。 这样的“函数计算持续交付场景”具备三方面优势：第一，开发者可以专注于业务逻辑开发，无需关注底层细节和资源情况，也无需关注服务的运维和治理。第二，能够按照服务使用量付费，减少资源成本，并且可以实现分钟级快速上线。第三，整个研发流程基于云效DevOps平台，由云效提供自动安全守护能力；运行环境基于阿里云提供的经过大规模商业实践的基础设施，稳定性好；同时“函数平台”天然具备高弹性，可以从容应对突然业务流量。 对于已经采用或准备采用微服务架构的中小规模开发者团队，推荐使用“云效+SAE”的持续交付方式。这种“微服务持续交付”具备如下特点：第一，Serverless 应用引擎SAE（Serverless App Engine）与spring cloud、dubbo等微服务框架深度整合，内建微服务治理能力，可有效降低使用微服务的成本。第二，基于秒级弹性能力，服务扩容快、弹性高，能够应对业务突发流量，可保障服务的稳定性。第三，内建微服务发布、运维能力，可有效提升微服务测试、发布、运维效率。 对于有自己的服务治理体系，希望研发有足够的灵活性，同时又能享受云原生和持续交付的技术红利的中等或大型研发团队，可以使用“通用云原生持续交付”解决方案。这种交付方式有哪些优势呢？首先，云效提供从需求到线上运维的一站式研发流程支持。其次，云效提供从基础设施到DevOps工具链的全流程安全防护。第三，与阿里云基础设施和云服务深度整合，具备免托管、高性能的特性；同时由于阿里云的基础设施是完全遵循遵循Kubernetes（k8s）开源标准的，所以不存在迁移成本。 截至目前，阿里云云效已经服务十万家企业、百万开发者，帮助众安保险、光大银行、天弘基金、南方航空、上汽通用、南京银行、万科、国泰产险、上海博卡、石家庄掌讯等众多企业成功完成DevOps转型。本次云原生DevOps解决方案的发布，云效希望可以助力更多企业迈进云研发时代，实现DevOps转型“超车”。 登录“阿里云云原生DevOps解决方案重磅发布”官网（https://yqh.aliyun.com/live/devops） 可以查看：发布会视频回放、下载PPT、体验云原生DevOps场景、免费领取23722元云效企业级一站式DevOps套餐等。
云效DevOps训练营第3期开营啦
课程概述： 在云研发的大背景下，企业的软件交付既面临挑战，也充满机遇。本课程将帮助企业通过建立云原生的基础设施、持续交付的工程实践和完整的质量守护体系这三板斧，来提升整体交付效率和交付质量，更好地应对业务的挑战。 课程纲要： 1、云研发时代软件交付的挑战与方案2、建立基于云原生基础设施3、 构建可持续部署的应用发布体系4、建立高效团队协同交付的流程5、提升应用发布的质量6、持续反馈、持续改进 服务对象： 中小型软件企业或进行传统企业数字化转型的CTO、CIO或研发负责人。 学员收益： 1、了解到云原生的基础设施及其价值2、能够针对企业制定适合的研发模式3、知道如何在企业落地持续交付实践4、知道如何建立适合的质量守护体系5、能够指导团队建设的方向。
服务概述： 公司业务高速成长，技术团队的规模也随之快速扩张，原来行之有效的方法面临巨大挑战。如何才能建立高效的研发体系，来满足业务快速创新的诉求？传统咨询顾问需要投入大量时间去了解情况、分析问题、提供方案、方案汇报、辅助落地实施的重咨询模式，通过2-3 次 1-2 天的研讨会，由阿里相关领域的 资深专家和企业管理层共同产出改进方案。相比传统咨询，既节省费用和时间，又贴合企业实际情况。充分的输入 + 先进的经验 + 即时的反馈 = 更优/更落地/更低成本的方案 咨询纲要： 现状梳理 改进目标设定 效能问题根因分析 组织阵型及协作模式 持续交付工程体系 效能度量体系 落地方案产出 服务对象： 处于快速成长阶段的中小型互联网企业的CXO、研发主管 学员收益： 1、系统分析团队面临的效能问题，并根据自身的特点产出效能改进方案； 2、了解典型的组织结构设计方法，以及配合不同组织结构的协作模式；3、了解业界持续交付工程实践，产出基于云原生的持续交付方案；4、了解效能度量体系设计背后的原则和方法，产出效能度量体系方案。 联系我们 如您对本培训感兴趣，可联系：胡晓艳 13867434327（钉钉/电话）
课程概述： 云原生时代，软件架构的核心关注点上移，业务架构、领域能力、资产沉淀构成了企业长期发展和快速业务响应的核心竞争力。这些也是中台化和微服务建设的最核心能力。同时，业务场景的复杂性，对企业的领域能力建设带来了巨大挑战。高质量的业务分析、领域建模、卓越技术实践成为CTO/CIO所面临的重要课题。本课程以领域建模为核心，介绍需求分析、软件架构、技术实现方面的核心实践和典型案例，帮助你建立卓越的中台技术能力。 课程纲要： 1.以领域能力构建云原生时代的核心竞争力，和中台化和服务化技术基础2.以领域为核心的软件开发技术体系——高质量业务分析、领域建模和卓越技术实践3.互联网时代的高效业务需求分析方法，案例演示及实践工作坊4.领域驱动设计和领域建模技术实践5.微服务设计及中台架构设计原则，及相关案例解析6.中台和服务化下的技术及工程实践7.中台化下的协作流程和团队能力建设，及资产质量维护实践 服务对象： CTO、CIO、架构负责人、关键技术骨干 学员收益： 1.系统化建立领域为中心的需求分析、架构设计的关键技术体系2.在业务架构层面清晰理解领域驱动设计的核心价值，支持企业的服务化架构构建3.学习和了解先进IT企业在中台化和服务化领域的先进经验 联系我们 如您对本培训感兴趣，可联系：胡晓艳 13867434327（钉钉/电话）
课程概述： 数字化时代，技术成为业务发展和创新的核心，提升研发效能成为产品技术团队的共同挑战。本次课程综合阿里巴巴和业界研发效能提升的最新实践，针对CTO和研发总监打造，为研发效能提升提供系统方案和可操作的落地实践，助力组织实现相对传统方法10倍效能提升，让技术成为加速业务发展和引领业务创新的核心。 课程纲要： 解析研发效能的内核，以及提升研发效能要解决的3个核心问题； 如何建设研发效能目标和度量体系，引导效能的改进提升； 研发效能提升相关的技术、工程、协作和创新实践； 应用系统思考方法，分析效能问题的因果回路，找到效能问题的根因，并设计效能提升的系统解决方案； 应用精益思维，针对效能目标设计组织流程和流程步骤中的规则； 如何设计端到端的数字化协作体系，及相关流程机制，实现研发过程的全链路数字化和数据化。 在过程中将穿插大量来自我们实际经历指导过的大量案例，包括曾经走过的弯路。 服务对象： CTO、CIO、研发和产品总监，效能负责人，特别是希望发挥技术在业务发展和创新中的核心地位的人员 学员收益： 可以系统分析组织效能问题，并根据自身的特征设计效能改进方案，并顺畅落地； 全面和系统了解业界最新研发效能实践（包括工程、技术、协作、创新等实践）； 剖析阿里及业界效能提升的典型案例，掌握效能提升路径模式，了解和避免效能提升中的坑； 了解效能度量体系设计背后的原则和方法，掌握完整的效能度量体系和定制方法； 了解典型的数字化和互联网时代的组织结构设计方法，设计配合不同组织模式的协作和流程体系。 联系我们 如您对本培训感兴趣，可联系：胡晓艳 13867434327（钉钉/电话）
今天来开启我们的第3关打卡任务：通过云效将ALPD项目源码自动部署到K8S集群上。 注意： 云效提供的免费的Docker镜像仓库和K8S集群资源已下架，如仍需体验，可使用自备资源，操作指引见：https://thoughts.aliyun.com/sharespace/5e8c387c0aa435001a74f7ab/docs/5f19008b6fd3fa0023fdcef5 打卡奖励 完成6天打卡任务，你将获得云效定制实物礼品；学完全部课程+6天打卡完成，将获得阿里云云效颁发的毕业证书哟~ 实操步骤简介： 1. 将ALPD项目源码导入到免费的云效代码管理Codeup中codeup.aliyun.com?channel=camp 简要步骤截图 2. 在云效流水线（flow.aliyun.com?channel=camp）中为三个应用分别创建一条流水线，监听master分支的代码变化，当有代码变化是自动构建并部署到云效训练营ACK环境（采用deployment.yml文件进行部署，通过$USER变量区分每个用户的deployment和service） 简要步骤示意： 3、最后在流水线添加云效训练营专用打卡任务，方便打卡校验 新建一个空白任务，命名：打卡，添加步骤选择“其他”-“DevOps训练营部署验证” 4、点击保存并运行，运行成功后，返回打卡页面，刷新几次，看到✅即为打卡完成 5、通过kt-connect连接到云效devops训练营的k8s集群，并能访问alpd-bot-${USER}-ssh服务，在钉群内晒出截图信息
2020阿里巴巴研发效能峰会——《ALPD - 驱动业务创新的精益产品研发》 摘要：ALPD是Advanced Lean Product Development（下一代精益产品开发）的简称，它的目标是成为支撑云时代产品开发和业务创新的实践体系。本次分享，阿里云云研发部资深技术专家何勉将为大家剖析研发效能面临的挑战，并详细介绍ALPD及应用实例，展现其是如何支撑业务发展并引领业务创新的。 演讲嘉宾简介：阿里云云研发部资深技术专家——何勉 以下内容根据演讲视频以及PPT整理而成。 观看回放 http://developer.aliyun.com/topic/2020 本次分享主要围绕以下四个方面： 一、研发效能的挑战 二、ALPD：阿里的精益产品开发方法体系 三、适配场景的ALPD效能解决方案 四、总结：提升研发效能，赋能业务创新 一、研发效能的挑战 1.阿里巴巴技术发展 下图为阿里技术20年砥砺攀峰背景墙，回顾了阿里巴巴技术发展的三个阶段，特别是技术与业务的关系。 1999年~2008年：技术支撑商业发展；2009年~2016年：技术拓展商业边界；2016年~，技术创造新商业。 2.技术如何创造新商业 技术与商业越来越不可分割，成为驱动业务创新的内核。下图展示了阿里的技术与业务的关系。 首先，最底层（或内核）的是云基础设施以及基于云基础设施的云原生开发和运行环境。 在云原生内核之上是中台，例如：阿里在中台2.0战略中所提倡的业务中台、数据中台和AI中台。以中台为基础，可以组合并拓展新的业务形态，快速满足业务需求，和创造新的业务形态。 技术要支撑业务发展，更要引领业务的创新。这对研发效能提出了前所未有的要求，要求技术、工程和协作方法和实践的全面升级。系统整合这些实践方法，形成可落地的解决方案，提升研发效能，从而持续降低创新的成本，提高创新的效率。这是我们探索和实践ALPD（下一代精益产品开发方法）的初衷。 3.研发效能面临的挑战 研发效能究竟面临怎样的挑战呢? 下图中，我们用3个 “≠” 来描述这一挑战。 第一：局部效率不等于高效交付。局部的效率是基础，但真正的效率，必须从用户视角来衡量——快速解决用户问题、快速上线用户的需求。为了做到这一点，只有局部效率是不够的，只有系统的协同和改进，才能高效交付用户（或业务）的需求。 第二：高效交付不等于持续高效。技术、工程等多重因素影响着效率的可持续性。做的不好，随着时间的推进，组织会积累技术和工程的债务，不但陷入维护的泥沼，软件的扩展也会越来越困难。不可持续的高效交付最终还会是竹篮打水。 第三：高效交付不等于业务成功。我们的目标是业务成功，但要想成功，必须保证交付的是用户和市场所需要的，并构建起合理的商业模式。在不确定性陡增的今天，这是一个不断探索和试错的过程，需要系统的创新方法。 研发效能的提升和保障，就是要解决好并避免这三个“不等于”。 “不等于”是从负面来描述研发效能的问题。对应的，从正面角度，我们把研发效能提升的目标定义为：“持续地、顺畅高质量地交付有效价值”。 如下图所示，下一代精益产品开发（ALPD）正是面向这一目标构建的方法和实践体系。 二、ALPD 方法学：下一代精益产品开发方法 阿里巴巴在实践中构建的产品开发和创新的方法，我们称之为ALPD（下一代精益产品开发）方法学。图中的屋顶——“持续地、顺畅高质量地交付有效价值”——是我们前文所述的研发效能的目标。其底层以及两侧灰色部分是基础设施和组织保障。 图中蓝色的部分，是关于精益交付的实践。具体包括：全链路数字化的精益协作、领域为核心的技术实践，以及云原生的工程实践。其中，精益协作实践保障顺畅和高质量的交付，技术及工程实践则主要保障可持续性。 橙色部分是用户目标驱动的创新实践。分为业务探索和创新实践，以及更上层的动态投资组合管理两个部分。它们共同保障交付有效的价值。 下面我们将介绍其中的核心实践。 1. 全链路精益协作 全链路精益协作由三个实践构成。分别是：拉通端到端的价值流；左右对齐和快速交付；保障过程和源头质量。 全链路精益协作实践一：拉通端到端价值流 组织内部往往看到这样的矛盾。一方面，各个部门或角色看上去都很忙碌；另一方面，用户的感受却是另一回事。这在产品开发组织中尤其常见 —— 产品、开发、测试等部门和人员都非常忙碌；而从用户提出诉求到需求上线的时间却很长，对外的响应很慢。 为什么会这样呢？如下图所示，绿色短线代表需求正在被处理，红色长线代表需求处于等待状态。我们经常看到，务求大部分时间处于等待状态。这就造成了，从组织和用户角度的不同感受。从组织视角来看，资源效率高——每个人或部门都很繁忙；而从用户视角来看，流动效率低——需求得不到快速响应。 等待处理时间长的原因很多，可能是：工作在不同角色间的传递和依赖；批量处理需求时大部分需求处于等待状态；问题和阻碍不能被及时处理；等待测试和批量发布等。这一模式下，工作量几天的需求，从提出诉求到上线的过程往往会超过一个月了，甚至达到数月。 除了各个环节之间的等待，中台化本身也对协作提出了新的挑战。中台化为产品研发提供了新的生产力可能，通过中台能力的沉淀和复用快速组合和满足新的业务需求。然而，生产力需要与之适配的生产关系。 中台化下，如果前、中、后台的协作关系处理不好，反而可能产生效能竖井，出现更多的依赖和等待，延缓而非加速需求的交付。这一情况绝非少见。 为了提高对外的快速响应能力，企业必须改变视角——从内部职能视觉的局部优化，转变为用户视角的系统优化。 从内部职能视角，我们看到的是相互割裂的局部，而局部优化往往会损害而不是提高整体效率；只有从用户视角出发，关注从用户提出问题，直到交付需求解决问题的全链路过程，优化整个链路，才能系统改进，提升用户可感知的研发效能。 以某个业务板块的协作改进为例，我们首先做的就是梳理并打通业务价值流，为此我们要做到两点： 第一，业务价值驱动。在相对复杂的业务中（如：产业互联网、供应链等），业务需求可能需要多个产品和系统的协作才能完成。正因为如此，在看板上流动的必须是业务价值——业务需求。只有业务需求才是不同职能有效协作的共同源头，是用户价值的基础，是协同各个职能和拉通端到端价值流的不二之选。 第二，前后职能拉通，关注并优化端到端的业务价值流。 以业务价值驱动为基础，接下来要做的是拉通前后职能。上图反映了业务价值交付过程——端到端的价值流。业务价值流串起了不同职能的工作。 可视化并管理业务价值流，让不同的职能更好的协作，优化端到端的价值流动，确保用户价值的顺畅交付。 下图中的小工具，展示了每个业务需求的交付时间线，它们在每一个阶段所停留的时间、阶段间的等待、目前所处阶段、是否发生停滞等。它帮助我们跟踪和优化业务需求的交付过程，即时发现问题，并处理过程中的停滞、等待等问题。 简而言之，团队必须关注并改善业务需求的价值流，围绕用户与业务展开协作，加速业务响应。 全链路精益协作实践二：左右对齐快速交付 为了快速交付业务价值，组织内部必须协调一致，做到左右对齐和快速交付，这里的左右对齐指的是开发任务或子产品需求向业务需求对齐。 在这个案例中，业务需求的交付，往往需要多个产品的协作。比如，一个业需求会被拆分到不同的产品。这样就形成了下图所示的分层价值流，它包含上层的业务需求价值流和下一层的产品需求价值流两个层次。 企业最终关注的是业务价值流动效率，这就要求价值流的下层向上层对齐。下图所示为价值对齐图，也是我们专门设计的工具。图中最左侧是业务需求，选中业务需求后，右侧是该业务需求拆分到各个产品的产品需求，以及这些需求的交付承诺和状态。 组织的目标不是追求局部效率，而是提升整体业务响应效率。决定业务响应效率的是瓶颈环节与产品。因此，我们要基于业务需求来对齐前、中、后台产品——对齐承诺，并即时跟踪产品需求状态，即时暴露并解决系统问题和瓶颈，加速需求的交付。 **全链路精益协作实践三：保障源头和过程质量**前后拉通、左右对齐，让整个组织围绕价值的交付更好地协作。为了让价值更顺畅的流动，我们必须要保障源头和过程的质量，减少因质量问题而带来的返工和等待。下面，简单分享一下保障源头质量的实践——实例化需求。 如果源头是垃圾，结果也会是垃圾，所谓“Garbage in，Garbage out”。与之对应，我们要做到“以终为始”——在开始开发前，明确定义和沟通最终结果应该如何，让各参与方对业务需求达成一致理解。 实例化需求是达成这一目的具体实践，它让开发、测试、产品、业务等角色可以共同参与，高效沟通和澄清需求，并以结构化的方式确保沟通过程的效率和效果，产出需求的验收标准。 源头质量得到保证，还让优化整个开发过程可能。上图表示了以实例化需求为基础，如何重构开发和验收模式。 1）在需求开发前各个角色共同澄清需求，包括：需求的目标；为实现目标而要支持的操作和操作流程；与操作流程对应的业务规则。这些流程和规则作为实例，不仅帮助不同角色共同澄清需求，建立对需求的共同理解，而且还成为将来需求的验收标准； 2）与开发过程并行，基于验收实例产出测试用例。条件和能力具备的团队还会将这些测试用例自动化； 3）开发完成后，第一时间用验收实例来验收需求，提供即时反馈。如此保证需求的过程和交付质量，做到真正的“以终为始”。 总结全链路精益协作的实践。我们分别通过三个实践，有机配合实现了顺畅和高质量地交付。它可以表示为： 顺畅高质量地交付 = 拉通端到端的价值流 + 左右对齐和快速交付 + 保障源头和过程质量 2. 云原生的工程实践 接下来，简要介绍一下云原生工程实践。实现业务的持续高效交付离不开工程实践的保障。它包含以下三个方面： 不可变基础设施：实现不可变的基础设施。它至少要做到：1）配置和镜像分离，做到一次构建在不同环境上（如开发、测试、预发、生产）的部署和运行；2）通过IaC（Infrastructure as Code）技术做到配置代码化，保障运行环境的数据和配置的一致性、可用性和稳定高效。云原生的技术（如：容器技术、服务网格、基于K8S的调度运维等）为不可变基础设施提供了有力的支持，而不可变基础设施也是高质量和高效持续交付流水线和质量保障体系的基石。 持续交付流水线：基于不可变基础设施，构建持续交付流水线。将代码提交后的所有流程（如代码扫描、系统集成、各类环境下的验证和部署等）标准化和自动化，并以此为基础，实现流程卡点、即时反馈和系统度量。如此，持续交付流水线建立了交付效率和质量的保障框架。 可信发布（质量守护体系）：在持续交付流水线的基础上，建立和不断完善质量守护体系。质量守护体系必须集成至持续交付流水线当中，确保质量保障手段在正确的时刻起到守护作用，并应用流水线的反馈不断完善它，包括：基本模块和接口质量的守护，基本的功能回归、合规性检查、性能、流量测试、安全检查等等。如此才能做到高效、高质量和可信的发布。 不可变基础设施建立了基础，持续交付流水线提供了基本机制保障，而质量守护则保障了可信和高质量的发布。云原生技术为它们提供了更优雅和有效的解决方案，它们共同构成了云原生的工程实践，保障交付的质量、效率的可持续性。 3. 领域为核心的技术实践 工程实践以外，产品开发的效率和质量提升，还是要落地到技术实践，包括：分析、架构和实现等。在现实中最挑战的是如何有机融合和落地这些实践。我们以领域模型为核心连通相关的技术实践，形成了下图中的“领域为核心的技术实践体系”。 1） 业务引领的领域建模：结构化分析业务需求，澄清业务目标，分析业务场景以及业务流程，业务流程步骤对应的业务规则，基于业务规则定义验收标准。在分析需求的同时，深刻洞察领域的本质，产出或演化领域模型。 2） 领域驱动的微服务架构：以领域模型指导架构的设计和分解，应用DDD（领域驱动设计）的战略和战术模式，分解子域，明确子域之间的边界（限界上下文）和设计契约，并落地为微服务架构，沉淀可复用资产。 3） 契约导向的软件实现：领域驱动设计明确了各个子域的边界、接口和设计契约，它们将成为系统实现的依据和约束；再结合分析过程中产生的领域模型和验收实例，指导高效编码与设计，产出有效的自动测试，守护系统的边界、接口和功能；测试守护将支持系统随业务发展的重构和演进，持续地支持业务的发展和创新。 以上三个实践，以领域模型为核心，有机整合分析、设计和实现过程，既高效的分析和实现业务需求，也保障了设计和代码的长期质量。它更好的支持中台战略落地，实现中台战略的初衷——以更优质的领域资产，更高效地支持业务发展和创新。 从中台的角度讲，如果中台是新的生产力，业务驱动的全链路精益协作就是与之匹配的新生产关系；领域为核心的技术实践则是新生产工具；云原生的工程实践则是基础设施。没有生产关系、工具和基础设施的支持生产力就无从兑现。 三、适配场景的ALPD解决方案 以上介绍了ALPD方法学（ALPD-Method），它提供了系统的赋能实践，描述了理想的产品开发和交付模式。只描绘理想模式是不够的。同样重要的是如何实施落地，特别是如何适配不同业务特征和场景给出落地的方案。这是ALPD 解决方案（ALPD-Solution）的目标。为了适配不同的场景，我们首先总结了从战略及业务到代码及变更的全链路数字化体系。它应该满足两个要求：1）打通从战略、业务到代码的全链路过程；2）能够定制化并覆盖阿里巴巴经济体以及业界的主要场景和业务。 基于这样一套基础方案，就可以去裁剪和定制，以满足不同的场景。如下图所示，该体系分为三层： 顶层为规划层，包含两个模块：1）业务和目标管理。它从组织战略和业务发展出发，组织和管理团队的目标，目标之间可以关联和引用，目标最终要与项目或需求关联；2）战役（和项目组合）管理。战役是有阿里特色的管理方式，它聚焦于组织的战略，分解和跟踪战役的目标，设定战役的组织阵型和项目组合，并跟踪和管理战役及关联项目的实施过程。中间为实施层，包含两个模块：1）产品管理，它承接战略和业务发展的目标，管理产品需求的规划和交付过程，并确保产品的演进和产品资产的有效沉淀；2）项目管理，它关注项目从启动到收尾的生命周期，确保项目的交付进度、范围、质量和成本。最下层为交付层，包含两个模块：1）交付团队管理，它负责管理团队的交付过程，如迭代计划，协作和进度跟踪等；2）持续交付，它是管理团队的代码提交、集成、验证直至系统和需求的持续发布。这三个层次，六个模块相互关联，构成了全量的方案。具体的业务和组织，可以基于这一全量的方案定制形成自己的全链路数字化解决方案。数字化模型是解决方案设计的基线，更重要的是在具体的上下文中，分析效能问题；设计改进方案；落地实施；以及设定牵引性的改进目标和度量体系。今天限于时间就不再展开了。 四、总结 “技术创造新商业”，技术在业务中的地位越来越核心，研发效能直接关乎业务发展与创新。提升和保障研发效能，是每一个产品技术团队的挑战。ALPD（下一代精益产品开发）应这一挑战而生。 ALPD源自我们在阿里巴巴经济体以及业界的长期和深入实践，目标是：相对传统的产品开发方法：10倍响应速度；10倍过程质量和10倍有效价值。 10倍效能提升绝不容易，不可能通过单一实践实现。它需要系统的方法实践——对应ALPD方法学；更需要可高效落地的解决方案——对应ALPD解决方案。 “技术创造新商业”，十倍效能提升是我们的长期愿景。期待将来为大家深入解读各个实践，不同场景下的具体解决方案和实施案例。
云效DevOps训练营第6天打卡任务 经过这七次课的学习，写一篇博客，并分享到钉群内， 例如，你可以谈谈： 课程中让你印象最深刻的内容 有打算去实践的内容吗？分享一下 有期望和大家继续交流的内容吗？分享一下
提交了问题
2020-09-02
提交了问题
2020-09-02
第1次实操任务，不少同学已经将在本地k8s集群中将三个应用部署起来，虽然过程中踩了不少坑，但是最终还是完成了，班班也替你们感到高兴。 今天，我们让我们一起继续实操起来吧！ 打卡奖励 完成6天打卡任务，你将获得云效定制实物礼品；学完全部课程+6天打卡完成，将获得阿里云云效颁发的毕业证书哟~ 实操任务 1、通过kt-connect（https://alibaba.github.io/kt-connect/#/zh-cn/）或其他手段连接到k8s集群，能在本地访问alpd-bot-ssh服务 2、将alpd-bot-ssh的conf目录下的json文件移除，改用configMap保存这些配置，修改alpd-bot-ssh的deployment配置文件，并部署到本地k8s中 3、写一个测试环境的deployment-test.yml，将alpd-bot-auth，alpd-bot-query，alpd-bot-ssh部署在同一个Pod中 完成任务的同学，可以在钉群打卡，晒出你第3步完成的任务的截图哟~ 钉群打卡方式：第2天打卡+你的截图+下面你的思考（可选） 前5个成功晒出截图的小伙伴，送优酷VIP月卡一份 思考与讨论： 1、第3步的做法利弊有哪些。 2、alpd-bot-query的WEATHER_API_KEY是一个定义在secret中的配置，通过环境变量的方式在应用中被使用，参照运行时配置的要求，现在的实现有哪些问题，怎么解决？ 工具与源码 云效开源工具KT-Connect：https://alibaba.github.io/kt-connect/#/zh-cn/ 项目代码见：https://code.aliyun.com/groups/alpd-demo
纸上得来终觉浅，绝知此事要躬行。任何技能的掌握离不开实操。 今天是我们课程的第一次实操任务，完成任务，你将收获： 1、奠定基础 熟悉本次课程的项目代码，方便后面实操任务的进行 2、技能掌握 本地如何用Docker做构建、用K8s做部署 3、打卡奖励 完成6天打卡任务，你将获得云效定制实物礼品；学完全部课程+6天打卡完成，将获得阿里云云效颁发的毕业证书哟~ 实操任务： 1、熟悉项目代码，项目代码见：https://code.aliyun.com/groups/alpd-demo 2、参照项目代码里面的README，在本地构建出alpd-bot-auth、alpd-bot-query、alpd-bot-ssh三个应用的容器镜像 3、在本地将三个应用容器运行起来 4、在本地k8s集群中将三个应用部署起来 完成任务的同学，可以在钉群打卡，晒出你完成任务的截图哟~ 操作指引: 我们提供的项目源代码由4个部分构成： • alpd-bot-auth：用户鉴权服务 • alpd-bot-query：查询服务 • alpd-bot-ssh：SSH服务端 • protos：接口IDL描述 每个应用的readme里面都有有构建和运行的说明，以alpd-bot-auth为例： 构建与运行 本地构建依赖docker环境，请提前安装好docker。 构建 make build# docker images # 查看是否有生成alpd-bot-auth:latest的镜像本地运行docker run -p 9001:9001 alpd-bot-auth单元测试(optional)要求nodejs环境。 npm installmake test 部署到本地k8s 请提前在本地安装好k8s环境（如minikube），并构建好容器镜像。 # kubectl apply -f deployment-local.yml# kubectl get svc# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE# alpd-bot-auth-svc ClusterIP 10.108.106.62 9001/TCP 17m# kubectl get deployments# NAME READY UP-TO-DATE AVAILABLE AGE# alpd-bot-auth-deployment 1/1 1 1 16m 视频演示 见课程学习群文件 炫耀一下你的成果吧 完成任务的同学，可以在钉群，大胆晒出你成功部署到K8s的截图哟~ 钉群打卡方式：第1天任务打卡+你的截图
云效DevOps训练营第1天打卡任务
提交了问题
2020-08-18
2023年01月
发表了文章
2023-01-06 12:05:09
发表了文章
2023-01-05 09:51:03
发表了文章
2023-01-04 14:49:00
2022年12月
发表了文章
2022-12-30 12:13:52
发表了文章
2022-12-27 17:46:09
发表了文章
2022-12-27 17:26:38
发表了文章
2022-12-27 15:44:49
发表了文章
2022-12-26 17:54:38
2022年11月
发表了文章
2022-11-08 10:40:28
2022年10月
提交了问题
2022-10-28 18:27:09
2022年09月
提交了问题
2022-09-28 16:41:38
提交了问题
2022-09-21 18:06:27
提交了问题
2022-09-21 18:04:07
提交了问题
2022-09-21 18:02:09
提交了问题
2022-09-21 17:58:28
提交了问题
2022-09-21 17:55:47
提交了问题
2022-09-21 17:50:40
提交了问题
2022-09-20 09:48:50
提交了问题
2022-09-19 15:31:28
发表了文章
2022-09-07 16:58:50
2021年11月
发表了文章
2021-11-29 16:52:24
2021年07月
发表了文章
2021-07-02 10:41:09
2021年06月
发表了文章
2021-06-29 16:36:00
发表了文章
2021-06-03 11:02:44
2021年01月
发表了文章
2021-01-28 17:42:18
发表了文章
2021-01-11 10:29:13
发表了文章
2021-01-08 16:15:02
发表了文章
2021-01-06 15:16:12
2020年10月
发表了文章
2020-10-21 15:35:04
发表了文章
2020-10-20 21:22:41
发表了文章
2020-10-14 20:47:43
发表了文章
2020-10-14 20:46:02
发表了文章
2020-10-14 20:43:00
发表了文章
2020-10-14 20:42:49
2020年09月
发表了文章
2020-09-04 11:31:23
发表了文章
2020-09-02 10:45:11
发表了文章
2020-09-02 10:35:25
提交了问题
2020-09-02 10:34:29
提交了问题
2020-09-02 10:33:44
发表了文章
2020-09-02 10:32:32
发表了文章
2020-09-02 10:31:47
发表了文章
2020-09-02 10:30:39
2020年08月
提交了问题
2020-08-18 07:30:10
发表了文章
2023-01-06
发表了文章
2023-01-05
发表了文章
2023-01-04
发表了文章
2022-12-30
发表了文章
2022-12-27
发表了文章
2022-12-27
发表了文章
2022-12-27
发表了文章
2022-12-26
发表了文章
2022-11-08
发表了文章
2022-09-07
发表了文章
2021-11-29
发表了文章
2021-07-02
发表了文章
2021-06-29
发表了文章
2021-06-03
发表了文章
2021-01-28
发表了文章
2021-01-11
发表了文章
2021-01-08
发表了文章
2021-01-06
发表了文章
2020-10-21
发表了文章
2020-10-20
提交了问题
2022-10-28
提交了问题
2022-09-28
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-21
提交了问题
2022-09-20
提交了问题
2022-09-19
提交了问题
2020-09-02
提交了问题
2020-09-02
提交了问题
2020-08-18
