DevOps 如何攻克研发流程六大痛点？

如今，各大企业都将技术研发中心定位于参与企业发展战略、重大的新产品、新技术的决策，是整个企业技术管理、决策的龙头和核心。而 DevOps 作为软件工程领域目前大家公认相对更好的一种工作方式和 IT 组织文化，近两年备受企业关注与尝试。

今天，就跟大家聊聊企业研发过程管理的 6 个痛点，和如何通过落地 DevOps 平台及解决方案处理这些问题的。

痛点 1

需求开发过程协作难 

很多团队的协作模式仍然是传统的 CMM 类的思路，概括一下就是“重型文档、低频交流”。日常的工作组织形式则五花八门，并且有很多用户一开始其实并没有做到所谓标准的“瀑布”，或者“敏捷”。他们可能非常在意文档的交接，但又很难做到事无巨细的文档，甚至文档后补也是常事；可能有 2-4 周一个周期的迭代或者上线窗口，却未必能做到在约定周期内将内容交付；可能排到每个工程师手里的工作除了新功能开发，还会有很多缺陷修复或者其他各种工作，而这些工作又未必会被认可投入工时；还有不同项目的工作任务较之而来，让人难免出错，以至于可能有时候都会忘记自己曾经投入工时做的工作。

所以，如何帮助工程师和工程师主管清晰、有效地解决个人和团队工作排程问题是在需求开发协作过程中的第一个问题，并且这其实也是对项目组和工程师的一种保护。

解决方案   

通过落地 DevOps 平台及解决方案，可以以“工作项（需求/缺陷/任务等）”为管理对象，以“版本”、“迭代”为管理单元，以看板、甘特图等为工具，将团队协同工作快速组织起来，建立可视化的管理方式，并且与上游的业务需求、下右的代码等关联起来。

痛点 2

研发测试过程缓慢 

管理者总是希望研发过程快一点，更快一点，希望尽快的交付业务价值。而研发团队此时便需要思考时间究竟要如何分配？哪部分花掉的时间是可以节省下来的？

对于一个生产级的代码工程（Project）来说，除了敲代码、思考、重构花掉的时间之外，其实有很大一部分是工程构建和测试时间。让我们把视角从某个工程师的身上转移到整个研发团队，如果每个人每天在工程构建和调试上花 2 个小时，那一个 10 人的小型团队一天的开销就是 20 小时，也就是超过 2 个工作日的时间，那如果周期放到一个月呢？

而现代化的软件开发，通过 DevOps 实践，可以将这部分开销大大降低。通过工具链的构建降低工程师的重复劳动时间，并自动化测试来快速回归并保证构建的质量基准。

解决方案 

通过落地 DevOps 平台及解决方案，大幅度减少团队花在工程构建、回归测试方面花费的时间。并且通过每日构建、特定分支合并构建等实践形式，避免在最终集成测试的时候才发现构建过程中的问题。

痛点 3

代码管理混乱 

通过观察，有大量的研发型组织，在导入 DevOps 之前，甚至都没有一个组织级明确的代码分支管理策略。有的组织在使用 SVN 时，仅仅是把 SCM 工具用来打 Tag ；有的组织虽然已经开始使用 Git ，却没有利用好现代化 SCM 工具便捷强大的分支管理能力；还有的组织在使用 Git 时，分支间的合并关系混乱。

代码是软件研发的核心产出物，是软件制品资产的基础。很难想像，混乱的代码管理模式中隐含着怎样技术风险。

除了规范性本身的问题之外，我们经常还会想看某个版本到底有哪些需求/工作内容，这些内容又对应了哪些代码的变更。亦或某些代码的变更是对应了哪些需求或者哪个版本，这些都是在代码管理领域应该被关注的内容。

解决方案 

通过落地 DevOps 平台及解决方案，可以结合不同的 SCM 工具，指定组织级的代码分支管理策略，规范化代码管理流程并降低代码背后隐含的风险。

痛点 4

手工应用发布 

国内很多用户的生产发布都是定期发布窗口，比如银行和运营商，一到周四或周五发版日，为了不影响业务，往往是深夜才开始发版，整个发布过程都是手工操作，是否能一次性成功，除了软件本身的质量外，全靠具体工程师是否能全神贯注，打起十二分精神来应对每一个操作，所以命令级的发布部署手册必不可少。

而有些大型行业软件服务厂商的解决方案是，给自己的复杂业务系统嵌入一个自研的小型发布系统，以降低自身的发布难度。而这对于甲方客户来说，就是银弹了吗？

你会发现可能一家银行的发布，不同的业务系统、厂商，会有不同的发布系统。嵌入自研的小型发布系统的结果很有可能就是为了解决一个问题，却造成了更多的问题。

解决方案 

通过落地 DevOps 平台及解决方案，可以建立统一的发布体系，并且灵活应对生产和非生产的发布场景。对于生产类发布场景，通过上线申请单、环境资源准备、发布流程编排等能力，代替原有人工发布的方式，降低相关工程师的操作风险与工作压力，将发布过程从“黑盒”变为“白盒”，可重复、可验证。

对于非生产类的发布场景，除了生产级的发布流程编排外，还可以通过流水线集成、容器云平台对接等方式，快速发布，减少等待时间，提速研发过程。

痛点 5

研发过程改进缺乏抓手 

研发过程如何改进，是 CIO 和研发负责人永远关注的问题之一。软件行业经过多年的发展，其本身的复杂性和工程管理的的复杂性已经得到大家普遍认可。在找到银弹之前，我们需要一个抓手，通过改进和优化软件研发过程和流程，来提升研发的质量和效率。

在传统软件开发开发的场景中，这只能靠专家的知识积累和责任心。我们可能会看到一个团队中可能会有一个“高手”，每天疲于奔命在解决各种技术问题；也可能会看到组织成立了一个“架构部”，但架构部一定能解决具体项目组的难处吗？还是只是做口头的架构评审？

所以如何让专家们的知识传递到整个团队？如何将行业最佳实践嵌入到组织的软件研发过程当中？如何去观察我们到底有多少问题？如何判断从哪里开始改进？这些都是过程改进中的核心。

解决方案 

要想解开这些难题，一方面需要组织建设上的改进，另一方面很重要也可以很快看到效果的方法就是搭建工具链并建设 DevOps 平台。通过搭建工具链，让研发过程中的各种产出物数据（流水线、代码、制品、测试文件等）沉淀下来；而 DevOps 平台的建设，更是能在此基础上，将过程数据沉淀下来的同时，将沉积在各个工具中的数据整合、呈现出来，让“数据驱动研发过程改进”成为可能。

痛点 6

组织级研发管理规范难以落地 

在推行组织级研发管理规定的时候，常常因为市场压力、计划时间限制、贵广执行难度等等各种错综复杂的原因而很难落地，最后导致研发管理规范成为一纸空文。不管是需求的分析流程/工具、代码的提交与合并策略，制品库的命名规范等等，研发的整个过程遍布了我们“希望规范而又难以规范”的情况。而在规范的另一面，研发团队也倍感焦虑，为什么在持续加班赶工的情况下组织仍然给我们增加额外的工作量？在规范落地过程中发现问题点并反馈时如何做到在真实准确的同时更容易被组织接受？

解决方案 

通过落地 DevOps 平台及解决方案，一方面可以将规范内嵌的系统和团队的日常工作中，另一方面还可以通过平台对研发过程和工具链过程数据的收集整合，将真实、清晰、有效的数据反馈给研发团队和组织管理者，通过持续的建设优化，形成可落地的、不断迭代发展的组织 IT 研发管理规范。

关于博云 BeyondDevOps 平台：

博云 BeyondDevOps 提供从“需求->开发->测试->发布->运维->运营”端到端的开发运营一体化平台解决方案，覆盖项目管理、研发管理、测试管理和运行管理的协同服务和研发工具支撑，将线下 IT 生产过程转变为线上高度自动化、可视化的 IT 生产线，提升产品研发效率，快速响应业务需求，保障工作质量，并通过度量分析、风险预判，持续提升 IT 运营能力。

作为率先通过中国信通院首批 DevOps 评估的厂商之一，博云 BeyondDevOps 平台获得 DevOps 应用开发域的最高级别——先进级认证。BeyondDevOps 的集成开发环境、代码托管、代码评审、编译构建、流水线、部署发布多项 DevOps 核心工具能力达到国内领先水平。