年度回顾:百度乔梁谈持续交付与DevOps

标签: 百度 持续交付 devops | 发表时间:2012-02-06 09:53 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

在刚刚结束的 第22期百度技术沙龙中,百度项目管理部乔梁( @乔梁QL)来到沙龙现场,并就持续交付、持续集成和DevOps等话题分享自己的经验,并对国内的发展情况给予了展望。

1.创业经历

十年前我也曾自己创业,虽然当时做得还算不错,但慢慢发现自己不是一个能把事业和生活安排得很好的人,于是决定继续回来打工。对于从事软件开发,估计在座的各位90%以上都与互联网行业有关,我属于不小心闯进了这样的一家互联网公司里面的这种。

2.持续集成与DevOps

我在项目管理部中的一项工作就是保证产品快速上线。持续集成在近十年来发展迅速。还记得09年的时候我做过一次演讲,当时也是类似今天这样的规模(260人左右),当我问到有多少人知道持续集成时,只有三个人举手,今天来看已经占到了半数之多,所以从规模上可以看出,持续集成发展的速度还是相当快的。那么持续集成到底是什么,对一个团队来说,它是开发人员和测试人员之间的一种沟通和实践,以及团队间如何合作。随着互联网的快速发展。如何将开发好的软件快速部署上线,如何完成最后一公里,也变得越来越重要,越来越明显。我们的软件研发周期在不断的缩短,如何使其更加快速的被用户使用,越来越成为一个焦点。在08年,在欧洲的软件行业慢慢兴起了一个名词——DevOps,实际上,DevOps还没有准确的定义,网上存在着各种各样的说法,我们甚至也可以将DevOps理解为是一种运动,那么DevOps能为我们解决什么问题呢?它可以帮助我们的交付团队和运营团队进行协作,保证软件更加快速的交付,得到用户的反馈。

3.持续集成经验分享

有些公司做得非常不错,举一个例子,在国外有家不太大的互联网游戏公司,他们的研发团队只有50人,但是每天可以实现50次的部署。可能会有人问,为什么每天能做50次的部署?其中一个最基本的思想是Learning From User,翻译过来就是从用户中学习。这其中的每一次改动,都会经过一系列的快速验证,最后再部署到线上。开发团队能够在这四五台机器上收集到用户的相关数据,然后通过对数据的分析结果进行参照,便可及时地调整产品的方向。这个公司叫 IMVU。大家可以去查一一个叫阿凡达游戏网站,属于游戏类型的社交网站。他们从代码Check in到上线只需要半个小时左右,这就是为什么他们能够在每天做50次部署的原因,当然并不是说所有的全都部署,他也是之前那种规模,互联网行业这种灰度部署。我知道这个是本身作为一种方式,那么这个叫持续部署,今年10月份我翻译了叫持续交付的书,里面也提到了很多很多的实践,我想这些实践对我们软件的快速交付,具有一定的借鉴意义,目前我做得工作也和这个相关。在百度也是在不同的产品线,帮助团队能够做到快速的交互。

4.未来的展望

将来我觉得持续集成仍会是一个不可否认的方向,10年前的企业级软件开发,有的经过半年的时间产品才上线,现在互联网的发展如此之快,漫长的上线周期俨然已经成为了历史。甚至包括一些基础软件的发布频率,发布周期也变得越来越快,所以我认为,将来在持续集成、在持续交付方面,国内会有一个长足的发展。

更多乔梁发布的文章请见: 乔梁在InfoQ的文章

相关报道

年度回顾:开源专家姜太文谈开源硬件

年度回顾:知名博客冯大辉的技术感悟

年度回顾:酷壳陈皓谈搜索和移动互联网

年度回顾:海豚浏览器刘铁锋谈Web App热点

DevOps相关文章:

测试自动化和持续交付

不同技术团队的配合问题及DevOps

建设DevOps能力,实现业务敏捷

DevOps,让持续交付成为可能

贾国清 是InfoQ中文站高级策划编辑,热爱生活,喜欢旅游和体育运动。

相关 [百度 持续交付 devops] 推荐:

年度回顾:百度乔梁谈持续交付与DevOps

- - InfoQ cn
在刚刚结束的 第22期百度技术沙龙中,百度项目管理部乔梁( @乔梁QL)来到沙龙现场,并就持续交付、持续集成和DevOps等话题分享自己的经验,并对国内的发展情况给予了展望. 十年前我也曾自己创业,虽然当时做得还算不错,但慢慢发现自己不是一个能把事业和生活安排得很好的人,于是决定继续回来打工. 对于从事软件开发,估计在座的各位90%以上都与互联网行业有关,我属于不小心闯进了这样的一家互联网公司里面的这种.

【DevOps进行时】持续交付广义流水线探索 – 农行DevOps实践之路

- - DevOps 博客
持续交付流水线是DevOps落地的重要工程实践,但是业界普遍把持续交付流水线建设等同于CI/CD,很多人觉得部署好Jenkins,配置个自动化job,能编译,能部署,能跑自动化测试就搞定了. 其实真正的持续交付流水线远不仅仅是这些内容,它应该包括从需求/创新的提出,到功能架构设计,计划跟踪,开发编码,编译打包,测试验证,投产上线,再到将实现的功能让用户使用起来的全过程.

探路持续交付

- gengmao - 梦想风暴
眼下的这个项目是一个有趣的项目,它让我收获极大的部分并不在于写代码本身,更多的是关于软件开发的“Last Mile”. 自动化,让团队从繁琐重复中解脱出来的一个重要途径,这是所有一切的基础. 在给InfoQ写的一篇文章中,我已经尝试总结了一些通用的内容,这里不再赘述. 之前参与过的一些项目,很大的一个挑战在于环境.

持续交付模式

- - 博客园_知识库
   英文原文: Patterns for Continuous Delivery.   当你有了持续集成需要的构建服务器和脚本之后,下一个问题肯定是:“我们该拿这些构建版本怎么办. ”持续交付,以自动化或半自动化方式,将构建版本从一个环境提送(promote)到更接近实际生产的交付准备环境;这常常是公司在这方面演进的下一步.

DevOps 实战

- -
DevOps 的 3 个支柱. 第 1 步:寻找合适的试点项目. 第 3 步:快速建立初期成功. 第 4 步:快速展示和持续改进. 第一阶段:每次提交触发完整的流水线. 第二阶段:每次流水线触发自动化测试. 第三阶段:出了问题可以在第一时间修复. 第二步:定义指标并达成一致. 第三步:建立自动化执行和检查能力.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

『DevOps 最佳实践』 — DevOps 实践

- -
Culture – 文化:公司各个角色一起担当业务变化,实现有效协作和沟通;. Automation – 自动化:在价值链中尽量除去手工步骤;. Lean – 精益:运用精益原则更频繁地交付价值;. Metrics – 度量:度量并使用数据来优化交付周期;. Sharing – 分享:分享成功和失败的经验来相互学习.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

『DevOps 最佳实践』 — DevOps 平台 - Ledge DevOps 知识平台

- -
DevOps 数字化转型框架. 企业为什么需要一站式综合研发平台. 越来越来多的组织开始搞敏捷和 DevOps 转型,打造了很多的 DevOps 基础设施,比如有管理需求的 Jira, 有持续集成的 Jenkins,有容器编排的 K8S 等等. 可是这纷繁复杂的 DevOps 工具链,同时也给企业带来新的困扰.

持续交付话题的一些讨论和心得

- - CSDN博客研发管理推荐文章
周末参加了在杭州举行的持续交付话题沙龙的讨论,将这次活动中的一些精彩问答和经验警句记录下来供大家参考:. ” 持续交付如何让老板看到价值. “,这是当时讨论的比较激烈的话题,大家形成的基本结论是可以通过衡量周期时间来看持续交付前后的变化,如果使用持续交付前的周期时间是1周,运用了持续交付后周期时间变为3天或者更少了那么就为公司提高了竞争力,就比竞争对手更快的退出新产品、功能了.