CODING 2.0:为什么我们需要 DevOps

栏目: 编程工具 · 发布时间: 5年前

内容简介:最开始做 CODING 的时候,脑海中的蓝图是开发者在这里讨论需求、布置任务、写代码,改代码,演示代码,完成相关任务,整套的开发操作都在这里。

CODING 2.0:为什么我们需要 DevOps

CODING 在前两天的 Kubecon 2019 大会上发布了 CODING 2.0 。这背后是 CODING 对研发管理和研发团队组建的思考。从 CODING 成立以来,我们一直在探索“ 让开发更简单 ”的方式。把“让开发更简单”这个大愿景进行拆分,具体到可量化的产品目标上去,实际上是希望通过 工具 的形式,可以减轻开发过程中的重复劳动,提高软件交付的速度与质量。

 云端开发的初心 

最开始做 CODING 的时候,脑海中的蓝图是开发者在这里讨论需求、布置任务、写代码,改代码,演示代码,完成相关任务,整套的开发操作都在这里。

所以当时的产品结构是: 轻量级的任务管理 - 讨论 - 代码版本管理 - 演示平台

在这套产品体系下,产品经理会把任务指派给设计师,设计师完成设计后,产品经理验收后再把任务指派给研发人员,研发人员推送代码后,可以在演示平台做演示给产品经理验收。这是一套非常适合小团队的工作模型,流程简单,反应快速,CODING 自己团队也在使用,并且支撑了 CODING 产品前期的快速起步,快速上线,快速响应反馈的开发节奏。

 企业在成长过程中碰到的实际问题 

很快,随着 CODING 业务的发展,CODING 的产品线越来越多,团队也越来越大,当团队到达 100 人的时候(其中 60% 都是研发),我们发现团队开始"管不动"了,最终的上线质量非常依赖部门 Leader 的管理能力和开发者的自我修养。 为了保证产品达到预期,我们制定了大量流程和规范,但这让我们的进度越变越慢了。我们一度非常苦恼,创业公司的优势在于极高的效率与极快的产品迭代,但如果我们在发展的过程中丢失了这样的优势,将会很轻易的被别人超过。

所幸我们并不是第一个碰到这个问题的人。 《人月神话》中有个很著名的观点:

Adding manpower to a late software project makes it later.

-- Fred Brooks, (1975)

如果希望用增加人力的方式解决软件的进度问题,只会让进度变得更慢。 ”因为:

沟通成本= n(n-1)/2 n=团队人数

举例而言 10 个人的团队将有 45 个沟通管道,当人数到达 50 人时,这个数字将上升为 1225 个。随着人数的增多,团队内的沟通成本将指数级上升。了解到问题出现的原因,也就知道了解决方案:“我们需要更多更小的团队”—— 通过将团队分成若干个内部闭环的小团队来降低沟通成本 。于是我们有了一个稍微敏捷一点的组织架构:

CODING 2.0:为什么我们需要 DevOps

这个工作方式敏捷的很不彻底,问题在于运维。考虑到线上稳定性及系统的耦合程度,无法将运维拆到各个团队中去,各个产品线虽然有独立的产品经理、设计师和开发者,但需要运维协助上线测试环境,再由测试进行 testing 和 staging 两个环境进行测试验收。大量的时间被无用的等待浪费掉了。

CODING 2.0:为什么我们需要 DevOps

同时,由于工作目的的不同,开发与运维的矛盾也日益加深,都觉得对方基础的工作没有完成。团队陷入了困境。

 我们需要 DevOps 

境中酝酿着机会,我们在与用户的交流中发现这也是大多数团队的共同苦恼: 团队如何组织才能最大化的进行软件产出? 各个角色之间天然的目标不同,使得”又快又好的上线“变得困难重重。

DevOps 的理念就是希望能打破这种屏障, 让研发(Development)和运维(Operations)一体化,让团队从业务需求出发,向着同一个目标前进 DevOps 不只是通过工具辅助开发完成运维的部分工作,更是一种软件研发管理的思想、方法论,所追求的是一种没有隔阂的理想的研发协作状态。

CODING 2.0:为什么我们需要 DevOps

实践 DevOps 的首要任务是需要对 DevOps 的目标和精神达成共识,并以此指导工作。据此,我们制定了从新的产品线开始逐步拆分微服务、优化白名单验收机制等改进措施,并制定了明确的时间表。长期来看,希望在更好的保证软件质量的同时,开发更少的依赖运维工作。

CODING 2.0:为什么我们需要 DevOps

后,团队开始尝试放大工具带来的效能提升。虽然之前也使用了不少工具,比如用 Jenkins 在本地构建持续集成,自建 Docker Registry 做构建物管理,使用 Excel 进行测试管理等。但相对零散,培训成本高,同时需要有人力进行选型搭建和维护,哪怕只放半个开发半个运维,一年也是小几十万的投入。

我们迫切的需要一套工具,上手即用,辅助我们提升研发团队的产出效能,而不是花费人力时间在进行基础设施的搭建上,但市面上完全没有这样的产品,我们的用户也存在类似的苦恼,只能用好几种开源产品进行搭建。

那 CODING 为什么不做一套这样的系统,让有同样困难的 DevOps 转型企业可以快速完成工具建设?“让开发更简单”作为 CODING 一直以来的使命和愿景,督促 CODING 团队为开发者提供更优质的工具与服务。加之 CODING 的核心业务——代码托管是 DevOps 工具的基础与支点,故从 2018 年年初起,CODING 就将产品目标调整至为企业提供一整套的研发管理工具。在一年多的努力下, 目前 CODING 已经全面开放持续集成功能及制品库的 SaaS 版本的服务,支持所有主流语言以及多种目标环境。

CODING 2.0:为什么我们需要 DevOps

 DevOps 开发工具链:代码即应用 

我们认为,在不远的将来,随着工具的成熟,我们将进入” 代码即应用“(Code as a Product) 的时代,开发者无需进行繁杂的其他工作,仅需完成代码编写,应用就自动运行,企业因此降低了运维成本,提升了软件研发部门的效率。

“代码即应 用”对工具的要求分三个阶段:

  1. 持续集成阶段 通过持续集成工具,运行设置好的执行命令,避免重复劳动。

  2. 自动化部署阶段 :构建的创建过程本身变得简单,无需学习额外的运维开发知识即可创建应用的发布方式。

  3. Serverless 阶段 :真正做到发布无感知,代码写下即发布。

C ODING 2.0 上线了持续集成及制品库的功能,标志着 CODING 正式进入持续集成阶段。 用户仅需推送代码或合并请求,即可出发持续集成进行构建、单元测试、安全扫描等工作,并生成制品存储在制品库。 提升软件交付的质量与速度,同时减少因为构建过程中引入”人“而带来的不确定性。

CODING 2.0:为什么我们需要 DevOps

  还有点想说的 

中国软件行业发展时间短,发展速度快,人才储备时间短,地位也比较尴尬,哪怕是软件服务起家的互联网公司,随着公司的壮大,业务部门的地位也逐渐高于软件研发部门。 除了在少量领域,中国企业在这一过程中,研发部门的内驱力往往被消磨殆尽。 加之软件行业人力成本不断增加,作为支持和成本部门,管理者也容易将软件研发部门视为成本部门,思路往往是“能否降低成本“。

但如今,瞬息万变的市场环境对软件研发部门提出了很高的挑战,这是困难但也是机会。 一支高效的研发团队,不光可以减少系统间的摩擦和浪费,让研发部门快速响应市场需求,还可以持续交付高标准的产品,让产品验证进入正循环,引领整个团队的价值实现。

但组建一支这样的团队,需要的远不止是工具,更重要的是团队领导者的经验,知识,和变化的决心。许多有先锋精神的团队走在改革的前面,CODING 在协助他们转型的过程中,也看到了他们因为改革所碰到的困难、权衡和进步之后团队爆发出的生产力。

我们希望可以看到更多的中国软件企业了解 DevOps 的精神,并应用到自己的团队管理中去,向中国和世界交付一流的软件产品。这个过程很难,但真的很值得。

点击阅读原文使用  CODING 2.0 

体验 DevOps  全工具链 敏捷研发

CODING 2.0:为什么我们需要 DevOps


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

理解专业程序员

理解专业程序员

(美)杰拉尔德·温伯格(GeraldM.Weinberg) / 刘天北 / 清华大学出版社 / 2006-7 / 25.00元

《理解专业程序员》通过行内专家的独特视角,介绍了如何成为优秀程序员,如何提高工作绩效等问题。全书由多篇讨论程序员职业的短文组成,内容精彩绝伦,是一部任何在这个变化急剧的领域工作的人都不可错过的重要作品。本书论述生动翔实——你肯定能从中认出你自己和你的公司的故事——因此不仅极富教益,而且读来也引人入胜。 各篇主题包括:对于专业程序员重要的若干问题,成为专业程序员的途径,在企业官僚体......一起来看看 《理解专业程序员》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

在线进制转换器
在线进制转换器

各进制数互转换器

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具