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 个。随着人数的增多，团队内的沟通成本将指数级上升。了解到问题出现的缘由，也就知道了解决方案：“咱们须要更多更小的团队”——经过将团队分红若干个内部闭环的小团队来下降沟通成本。因而咱们有了一个稍微敏捷一点的组织架构：

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

同时，因为工做目的的不一样，开发与运维的矛盾也日益加深，都以为对方基础的工做没有完成。
团队陷入了困境。

咱们须要 DevOps

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

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

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

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

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

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

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

咱们认为，在不远的未来，随着工具的成熟，咱们将进入“代码即应用”（Code as a Product）的时代，开发者无需进行繁杂的其余工做，仅需完成代码编写，应用就自动运行，企业所以下降了运维成本，提高了软件研发部门的效率。

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

1. 持续集成阶段：经过持续集成工具，运行设置好的执行命令，避免重复劳动。
2. 自动化部署阶段：构建的建立过程自己变得简单，无需学习额外的运维开发知识便可建立应用的发布方式。
3. Serverless 阶段：真正作到发布无感知，代码写下即发布。

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

除工具外，CODING 还为企业提供研发流程实施的指导培训、敏捷训练等额外服务。目前已有几十家企业将 CODING 的 DevOps 工具应用到内部生产中，大大提高了团队 DevOps 转型的效率。

还有点想说的

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

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

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

咱们但愿能够看到更多的中国软件企业了解 DevOps 的精神，并应用到本身的团队管理中去，向中国和世界交付一流的软件产品。这个过程很难，但真的很值得。

点击使用 CODING 2.0

体验 DevOps 全工具链敏捷研发