028网站建设,深圳做网站建设开发,做淘宝设计能做网站吗,企业手机网站建设精英研发效能分为两块#xff0c;一是用技术的更新来提升效率#xff1b;二是提高整个技术生态中的协同效率#xff0c;激发技术活力。阿里巴巴技术团队在此基础上要实现的终极目标是打造7*24小时灵活发布的通道#xff0c;以及提供更快的业务代码迭代能力。今天#xff0c;阿… 研发效能分为两块一是用技术的更新来提升效率二是提高整个技术生态中的协同效率激发技术活力。阿里巴巴技术团队在此基础上要实现的终极目标是打造7*24小时灵活发布的通道以及提供更快的业务代码迭代能力。今天阿里巴巴高级测试开发专家傲野为你带来关于研发效能的一些思考希望对你有启发。 7*24小时发布窗口的实现其实并不简单受限于很多因素。我简单地进行了分解。 一、系统
先从最基础的开始说当一个创业团队只有几个人一两个系统的情况下是可以不考虑研发效率这回事的。因为不存在系统间的依赖系统内的依赖也完全在一个可控的范围内本地起一个 Tomcat 或 Apache 就能开发、调试。另外再加上团队成员之间的高频交流基本上可以实现随时随地想发就发的要求。 当业务逐渐复杂开发人数扩展到10几个人时。提效的第一步是理清系统内的依赖关系并促进角色的专业化。这也是大家所熟知的MVC通过对视图、模型、控制器的分离对系统内的逻辑进行分层。把复杂的代码逻辑下沉到Model层而视图层交由更专业的前端来负责。 当然在系统内部仍然有一些扩展的空间比如模块化为不同的业务划分bundle等。但仍然没有突破本身的瓶颈而且单一的系统也很难突破机器的特性。
二、架构
当技术团队已经达到几十个上百人的规模当业务已经无法通过单一的应用来进行水平扩展时。分布式的架构是解决问题的有效手段。在07年时阿里集团就在推进SOA化无论是淘宝还是支付宝原来的单一应用不断被拆分出来也在此时承载服务化中枢的消息等中间件蓬勃发展。 这种方式实现了系统之间的解藕激活了技术人员的生产力同时增大了系统的弹性实现了服务能力的低成本水平扩展。但因为复杂的调用关系对于某一个贯穿多个应用的项目来说无疑增加了集成的成本和质量的风险。
同时如果对应用规模不加以规划和控制的话会导致应用数的不断扩张从而影响到整体的开发维护成本。
三、配置管理
在5 - 10年前阿里是有一个专门的岗位叫SCM的负责技术团队内的代码管理配置项管理和应用部署。特别是在服务化初期开发人员的coding生产力被极度释放应用数出现一个井喷对配置管理的需求不断增强并最终促使了配置管理的变革。
在讲配置管理前先讲讲代码分支管理机制。这也是很多研发模式变革的起点。在此笔者先表达自己的观点没有对与错先进与落后的代码分支管理机制只有适不适合自己团队当下以及未来发展的管理模式。
先从大的层面上来说我们当前所讨论的都是为了解决并行开发的问题即有多个项目或团队对于同一系列应用进行功能开发。如果仅仅是串行开发是基本不用太考虑代码管理策略。
1、分支开发、主干发布。核心理念是使用固定的主干作为集成分支。使用分支进行开发在合并到主干分支后生命周期终止。当然除此之外还有紧急发布分支等。 2、分支开发、分支发布。发布成功后执行写基线操作确保主干的及时更新和稳定。同时分支发布的方式不依赖于大集成保持很强的灵活性。 体现在项目上的流程为 3、其他模式主干开发、分支分布等。由于我们并不常用所以略过。
平台化的支持早期配管的人肉化也造成了代码集成和部署的效率很低。不同角色之间的协同靠人来完成。因此在那个背景下还需要一个配套的PMO组织来保障。在这样一个历史背景下Aone对外版本是云效也孕育而生从平台化的角度来解决研发过程的协同、构建、集成和测试几个复杂的过程。为了更清楚的了解那个时期的痛点我找了2009年左右的Aone的蓝图可以管中窥豹这个时期我并没有亲自经历过只是针对于当时的前辈做了些访谈和收集了一些资料。我猜想也正因为这条道路面向未来解决问题造就了现在的Aone平台。 四、测试
当一个技术团队小负责应用少以及业务的用户群体少时是完全可以不用测试的。只有当业务发展到一定阶段用户对于质量的容忍程度越来越低时才引入专业的测试角色。其次在软件离线交付阶段由于软件的召回成本很高所以对于测试是不遗余力的但随着在线交付时代的深入测试团队是否能够快速的实现软件质量的评测反馈成为一个非常关键的问题。而也决定着在打通上述各个环节后7*24小时软件持续交付通道是否能够真正实现。
在讲之前我们再回顾一下上个章节。Aone平台实现了开发代码、配置、应用部署的在线化现在只剩下最后的一环测试。从2010年以来B2B的测试团队就希望可以把分层自动化平台跟Aone研发协作平台绑定在一起通过系统调用的方式来实现一个测试的快速验证机制并最终实现回归测试过程中的无人值守。 这个意义非常重大。应用的服务化后技术的风险实际上是收敛的大家都可以面向服务来进行开发实现高内聚、构耦合。并且应用的发布也更加灵活了。但对于测试来说却是极大的挑战。
1、测试的层次增加了。
2、测试的轮次变多了。每次集成每次发布就有可能是一次完整的测试回归。 就如Aone的推进间接取替了SCM这个角色一样。研发平台的快速发展和业务7*24小时发布的诉求也开始冲击测试在代码集成后的快速反馈能力。这是一个挑战也是一个机会。否则前期释放出来的所有生产力最后全都被卡在了测试这最后一个环节而且没有办法拆解每拆解出来一个测试工作量就增加一倍。只能通过不断叠加集成的应用量来提高集成测试的效率。 经过1688测试团队几代同学的努力现在我们在这个方面总算有了些成绩。我们已经通过分层自动化体系实现了60%以上发布测试的无人值守并且全年拦截故障在数百个级别含页面、UI等。 它的实现逻辑如下 五、文化
至此真正所谓的7*24小时业务的持续交付通道已经完全打造出来。我们再回顾一下。 1、应用内的架构分层前端、后端、测试各应其职通过专业化的力量激发了一轮生产力。
2、服务化的架构让技术人员可以面向服务来进行业务的开发实现了架构上的高内聚低耦合。进一步释放大规模技术团队的活力。
3、研发平台的搭建提供了持续交付管道实现了开发、测试过程的快速、准确传递。
4、依托于研发平台实现了环境的自动化部署应用监控代码检查。扫除了研发过程的基建设施。让技术人员聚焦于代码的生产。
5、测试自动化验证体系减少系统集成风险提高集成的频率。最终实现了代码的快速上线。
原文链接 本文为云栖社区原创内容未经允许不得转载。
