了解了这些规范，实际应该怎么去落地？在建设 DevOps 的过程中常常遇到许多令人痛苦的问题。比如，针对金融行业大量已有系统，研发管理模式不尽相同，规范过多该如何管理？新老系统和业务如何兼容？随着时间增长、流程紧急、业务压力增加，如何保证团队的热忱和规范的持久运转？规范需要对应的人员去支撑，工作场景往往相当复杂，如何做好规范的标准化工作？CODING 基于之前的经验，针对这些痛点研发了一款研发规范产品 TCMS，定义不同的研发团队所对应的研发管理流程，能够约束对应的需求、代码、流水线管理，做标准化的约束来提升整个团队的协作效率。
研发管理包括几个部分。首先定义研发工作流，需要定义代码能拉出哪几个分支，允许哪些对应的合并策略，并且每次合并必须要有对应的规范和理由；第二，不同的合并规则意味着不同流水线的执行，在合开发分支的时候，开发人员做了一次本地提交可能只需要运转开发流水线，只需要对代码的质量和单元测试做一些约束即可，一旦涉及到 release 分支或 MR 的合并，这时候意味着功能合流了，基于合流规则来关联流水线，在流水线过程中去约束这个合流所对应的业务规则；第三，自动化工具辅助分支管理，如果定义了一个分支只能拉出来一周，一周之内必须合并进去的话也会做一些约束；第四，将对应的分支和需求管理关联起来，分支在合流的时候能够很清晰地从需求管理追溯到代码开发，从代码开发再追溯到整个业务合并，全生命周期管理是可控制和便于查阅的。
下图为 CODING 的标准化流水线：
从 CODING 当前服务的客户，一块是移动端的业务，当前移动端 APP 已经越来越多的企业重视云原生，针对移动端也是能够基于云让开发速度得到更好的保障另一块是从金融行业，有些营销类业务更多适应云原生的场景。无论是营销类也好，还是 APP 类也好，核心挑战是 C 端用户过多的情况下业务会受到较大制约，比如收集更多的用户数据，更快速地对用户诉求得到反馈。单单通过流水线建设是无法达到这个效果的，流水线只能帮助我们更快地实现代码到构建到部署这一段的效率，但是之后怎么基于部署的应用来提升业务价值，就涉及到价值交付的过程。在当前的 DevOps 2.0 里面，运营过程和业务分析过程被纳入到 DevOps 体系里面去实现相应的价值交付。
那么怎么做价值交付？CODING 第一步会做自动化，第二步会做敏捷。至于为什么把敏捷放在 DevOps、自动化之后去建设，CODING 发现，在国内、尤其是大型机构和金融企业里面，敏捷没有推得像大家想象的那么好。自动化设备没有做到一定程度的时候是不足以支撑过于短平快的迭代的。所以 CODING 首先通过可靠可重复的流水线建立自动化的应用交付体系，帮助代码能够更快上线；然后基于敏捷的思维和实践对业务需求做拆分和管理，通过迭代做增量式开发。另外随着对迭代的要求越来越高， CODING 每天都会进行发布，敏捷已经不足以支撑业务需求的增长，因此 CODING 团队更加贴合互联网模式去做微服务改造，应用架构变化之后，应用更小更细，就能更快地实现迭代。最后，业务上线之后运营过程也可以纳入到对应的 DevOps 体系里面来。
下图为 CODING 在价值交付体系下的组织结构转型：
在价值交付体系里面，CODING 从组织、流程、能效和工具四个层面做梳理。基于对应的 DevOps 指标能够评估团队对应的 DevOps 能效如何，怎么基于这些指标进行提升。
通过 DevOps 的建设，企业能够通过容器化构建和开发环境管理，降低资源利用率和节省成本。CODING 提供了构建的资源池，大家在做开发的时候不需要自己管理服务器；另外，通过 CODING 流水线建设做到对应的持续交付的效果；基于 CODING 的实施也能更好地建设符合 DevOps 文化的度量体系；标准化制品管理能够管理制品模板、流转和进阶的过程；最后，基于研发规范的约束能够让整个团队在落地 DevOps 的时候更加无感，大家自觉遵守约束以提高开发标准化。这是 CODING 的愿景——让开发更简单。
Q & A