战“疫”期，阿里云云效团队在家高效开发实录

【如下内容为分享实录，有删节】

如何解决在家办公时 “团队沟通”和“研发流程”问题
软件研发团队在家办公时，会遇到的两个核心问题：团队沟通和研发流程。由于云效团队本来就分布在多个城市，平时的沟通方式也常常采用“在线会议”，因此“在家办公”期间大团队之间的沟通协调受到的冲击较小。 可是小团队之间的沟通仍是遇到一些问题，平时你们坐在一块儿，有事情“吼一声”就解决了，远程办公确定没法作到。通过10多天的磨合，咱们逐渐解决了这个问题，提高了沟通效率。下面以云效团队为例，简单介绍下在公司办公和在家办公之间的差别。

“晨会”和“周会”上沟通的内容基本没有变化，主要是会议形式不一样。在公司咱们都是面对面交流，而在家办公，会采用电话会议和视频会议的形式。同时为了提高沟通效率，咱们在会前须要同步我的工做项、明确会议主题。在家办公期间，除“周报”外，咱们增长了“日报”，主要是为了在天天下班前披露我的工做进度和可能存在的风险。

在“研发流程”方面，若是你的团队不是采用“在线化”“白屏化”这种标准流程的话会遇到比较大的挑战。一旦在发布过程当中遇到问题或故障，在家办公时，不像在公司能够很方便的找到人，这会形成问题的放大。阿里巴巴在研发流程方面一直是作得比较好的，咱们主要经过“Aone”（云效是阿里巴巴自研的DevOps平台，内部名称为Aone）这个研发工具来承载整个研发流程的，包含了开发、构建、部署和安全生产等流程。

在家办公期间，咱们主要是经过“敏捷研发”和“持续交付”来解决的“团队沟通”和“研发流程”这两个问题，接下来，会详细介绍一下咱们是怎么作的。

以迭代为核心的敏捷研发
“敏捷研发”实际上是一套很是成熟的方法论，可是所谓“一千我的心中有一千个哈姆雷特”，每一个研发团队都应该“理论结合实际”磨合出一套符合本身团队的方法和机制。经过云效团队的实践，咱们认为：敏捷研发应该以迭代为核心，其中的关键是要进行“异步沟通”。

为何这么说呢？由于“迭代”是长期或者最终目标的拆解，当大的目标变成小的目标以后，咱们的团队会对这些“小目标”更有感知。当以迭代为中心后，咱们会将这些“小目标”再拆解成“工做项”或者“看板”上的“卡片”，并落实到每一个人身上，这也就造成了“异步沟通”的基础。

“异步沟通”相对于“同步沟通”，优点在哪里呢？首先，可以积累“上下文”。异步沟通时，咱们沟通的内容都会记录到工做项上；而同步沟通，更多的是以口头传达。其次，这也让每一个人能明确本身的目标，让你们保持专一，减小打扰，从而提升效率。

云效团队会将“工做项”分红三类：平常缺陷、项目需求、产品需求。“平常缺陷”很好理解，主要是对已上线产品的维护性工做，缺陷来自用户反馈或自测。“项目需求”通常比较复杂，交付周期较长，有明确的交付时间，来自企业客户或者企业自身内部需求。“产品需求”更可能是面向大众，须要持续演进。接下来，咱们介绍针对这三种不一样的工做项，云效团队是如何进行实践的。

如何处理“平常缺陷”。首先，云效团队会将“平常缺陷”分红四个类别：紧急缺陷马上修复；一周内修复缺陷；两周内修复缺陷；不修复缺陷。为何这么作呢？由于“缺陷”相比于“需求”来讲，是更加“明确”的，变化比较少，你们在认领的时候，基本能够确认什么时间能够完成。

第二，缺陷不会占用“故事点”。背后的含义是，不会把修复缺陷的时间计算到你正常的工做时间里，要求你们利用空闲时间去完成。这其实创建了一套正向激励的机制，由于“任务”和“需求”的工做项会带来必定的缺陷，当你的工做项完成的质量越高的时候，相应的，你的缺陷就会越少。反之亦然。这个机制就鼓励你们尽量的把本身的工做项作到最好。

第三，晨会不过缺陷，而是在周会核查上周缺陷进度，确认新增缺陷分类和指派人。
这套机制很是简单，而简单的机制其实更利于执行。云效在践行这套机制处理平常缺陷后，咱们本身的产品质量也获得了很大的提高和保障。

如何处理“项目需求”。 项目需求通常有肯定的完成时间点，且需求明确。咱们会根据肯定完成时间点，倒推关键时间，明确里程碑。这样作主要是为了更好的把控风险。须要注意的是，里程碑的内容必定是可量化的、可观测的。而后咱们会根据里程碑造成迭代，每一个迭代开始前作需求澄清和故事点评估。这样作跟敏捷研发方法论其实是一致的。须要注意的是，在团队培养方面，每一个人的技能应该是尽量均衡的。这样咱们从迭代拆解出来的“工做项”或“卡片”， 任意一个开发者均可以作，而不会和特定的人绑定。这样就不会由于某一位开发者技能的不足而造成瓶颈。

如何处理“产品需求”。 产品需求和项目需求工做项上的处理比较相似，都须要作需求澄清、故事点评估，而后在“站会”上进行“卡片”认领，风险预警等工做。主要的差别点是产品需求的迭代周期相对固定，这有益于保持产品稳健的延续性。若是迭代周期有时长有时短，这意味着在一样的研发周期中开发者处理的“卡片”数量是有稀疏的，这就可能形成交付质量的差别。另一个不一样点是，产品需求的迭代目标通常是根据用户、市场和数据的反馈而产生的，存在必定的不肯定性。这就要作一些“需求澄清”，在需求评审上也会更细致一些。

云效在践行敏捷研发的过程当中取得了很好的效果，团队成员也比较有成就感。咱们的一个心得体会就是：找到团队的节奏很是重要。但愿你们也可以在敏捷研发的实践中，找到本身团队的节奏，探索出一套适合本身团队的敏捷研发机制。

如何经过“持续交付”实现研发流程标准化
下面给你们介绍一下云效团队如何经过如何经过“持续交付”实现研发流程标准化。咱们常见的持续集成、继续交付都是经过“流水线”去完成的，今天主要给你们介绍一下云效除流水线外，比较有特点的一些实践，包括测试环境：微服务架构下，开发测试环境隔离方案，实现云端开发； 分支管理：多人研发协同下代码分支和静态配置项流程化管理；安全生产：软件交付保障，过程标准化，交付可追溯。

测试环境。先介绍一下咱们作这个解决方案的背景，以前咱们开发的都是“巨型应用”，随着微服务架构的演进，巨型应用开始拆分红不少小的应用。微服务架构带来益处的同时，对开发过程也带来新的挑战。首先，应用愈来愈多，应用链路就会变得很长，总体的开发资源有限，而且不稳定，致使整个开发调试过程比较困难。而在开发过程当中，你又须要一套独占的环境。用什么方法可以解决这个问题呢？

第一种方法，当我须要一套独占的环境时， 就把整个环境所有的应用都拉起来。这个方案有一些弊端，第一，随着应用愈来愈多，若是每一个应用的开发者都但愿把整个环境的所有应用拉起来，在开发资源有限的条件下，是没法实现的；第二，随着应用的增多，整个微服务架构就已经变得“难以描述”了，即便是一次完整的拉起也很难实现。

第二种方法是目前你们采用比较多的，咱们首先创建一些公共的基础环境，好比测试环境、预发环境等。当我须要开发的时候，我在本地起一个服务或应用，跟公共基础环境进行联调。这个方案也存在一些弊端，首先，在开发一个功能的时候，你要改动的应用可能不止一个，你须要把这些应用都部署到公共基础环境中。可是开发过程当中的服务或应用又是不稳定的，进而会形成公共基础环境的不稳定。此外，这样操做也会造成一种对公共基础环境的抢占。这种“抢占”使公共基础环境成为了开发过程当中的瓶颈，很是影响开发效率。

经过对以上经验的总结和实践的积累，阿里巴巴设计出一套“隔离环境”的解决方案。如上图中所示，当你须要作一些有特性的开发时，你不须要把应用或服务部署到公共基础环境中，而是单拉出来一部分资源为你的特性开发作部署，同时把这个“特性环境”和“公共基础环境”作一个打通而且隔离。你们能够共用一套资源，可是相互的请求又是隔离开的。这样操做的好处是，第一你不会占用大量的开发资源；第二，不会影响公共基础环境的稳定性。

“特性环境”实际上是一套虚拟的环境，从表面上看，每一个特性环境都是一套独立完整的测试环境，由一系列服务组成集群；而实际上，除了个别当前使用者想要测试的服务，其他服务都是经过路由系统和消息中间件虚拟出来的，指向公共基础环境的相应服务。

这套测试技术在阿里巴巴内部已经通过几代的演进，最开始是对要使用到的中间件（微服务中间件、消息队列中间件等）进行改造，使中间件支持这样的隔离机制。随着云原生技术的发展，我已经在使用Service Mesh的能力进行隔离。同时，咱们也开发了一款产品KT Virtual Environment，目前已经开源，欢迎你们在上面提缺陷。

分支管理。云效团队以及阿里巴巴内部研发团队基本都是采用“AoneFlow”这种分支管理模式。这个分支管理模式是通过多年实践积累而产生的，它经过变动模型，管理了Feature分支和静态配置项；代码分支和静态配置项合并、冲突解决都是经过白屏化来处理的；它和咱们常见的固定分支管理模式不一样，它的发布分支是动态的，能够实现Feature灵活组合，快上快下。为何要用“动态发布分支”？第一，咱们发现相比于传统的“巨型应用”，在微服务架构下，整个集成验证会变得很是困难。由于你须要在公共环境中与其它应用一块儿进行集成验证，即便在单体验证时你的代码是OK的，也很难确保与其它应用一块儿集成验证时你的Ferture分支是可靠的，一旦出现问题就须要从发布分支中退下来。第二，当多人协做共同开发一段代码分支时，你很难确保跟其余人集成时不出现问题， 并且发布频率越高，这种不稳定性就越大。特别是咱们的互联网企业，整个迭代速度很是快，开发频率也很是快，相应的出现冲突的可能性也会很是大。在这种状况下，你就很难确保在集成验证时你的代码分支是可靠的。这两种状况，都要求代码分支要“快上快下”。

安全生产。刚才咱们提到的“测试环境”和“分支管理”主要是从效率的角度考虑如何让持续交付作得更好，其实还有更重要的一点是怎样让交付质量获得保障，作到发布过程0故障。

首先，咱们要创建起一系列安全机制，好比安全扫描、Code Review等， 让“测试左移”，在开发阶段就发现问题。第二，这些机制不能仅仅是口头约定，咱们须要有效的工具来管理这些机制。云效团队将这些机制变成“卡点”“红线”集成到研发流程中，经过“云效流水线”来承载。同时为了平衡“效率”问题，云效团队更多的是对“增量”进行质量要求，对“增量”设置单元测试、代码静态扫描、集成测试、覆盖率等质量红线卡点。第三，是要作到人工审核和变动封网的全局维度管控，经过人工的方式与前面介绍的技术手段相结合，造成互补，来确保安全生产。

全新云效即将上市 敬请期待

近期，阿里云·云效会有一个全新的版本上线，带来全新的产品功能和使用体验。这是咱们聆听了来自各个渠道开发者的反馈，和众多中小企业开发者共创，用心打磨的一款产品。你们能够加入云效开发者交流群（钉钉群号：23362009）进行内测申请和讨论。

---

【下期预告】

【直播日期】4月15日 16:00
【直播主题】阿里的Kubernetes测试环境开源工具箱
【直播讲师】林帆 阿里巴巴技术专家
【观看方式】云效开发者交流群直播（钉钉群号：群号：23362009）

【直播预告】https://yq.aliyun.com/live/2618

【关于云效】
云效，企业级一站式DevOps平台，源于阿里巴巴先进的研发理念和工程实践，致力于成为数字企业的研发效能引擎！云效提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具，经过人工智能、云原生技术的应用助力开发者提高研发效能，持续交付有效价值。