正文
所以，DevOps 绝不只是互联网企业可以实行，对于传统企业而言，更加适合。通过建设 DevOps 平台来大幅提升软件研发效率，提升对市场的响应速度，支撑企业的数字化转型，也许对于传统企业而言，DevOps 平台带来的价值才是更大的。
清楚了 DevOps 平台的定位，也明白了 DevOps 平台对于任何企业都是可以实现的，那么还是回归到自身上，需要结合企业自身的现状思考下：到底 DevOps 能给自己的企业带来什么样的业务价值呢？DevOps 平台的理念固然是将软件研发的全生命周期管理起来，但是并不意味着一定要做到全生命周期的管理，落实到企业内部，终究还是要结合企业的现状和实际的需求，有选择性有目标的去建设。比如某企业由于组织的问题无法打通整个生命周期，那么通过持续集成、自动化测试、自动化部署等能力，提升软件交付的效率也是极好的。
对于企业而言，不管是提升 IT 的运营效率 70%，还是做到开发测试环境的持续集成、自动化测试、自动化部署，亦或是一天部署 10 次这种 DevOps最初的目标，最重要的还是要结合现状，先认清 DevOps 能给企业带来什么样的业务价值。
Step 1 梳理企业的流程和规范：
梳理企业的流程和规范是企业建设 DevOps 的前提，甚至即使不建设 DevOps 平台，这也是一个必不可少的行为。只有统一了企业的流程和规范，才能建设出一个适用于企业的 DevOps 平台，否则到最后，有可能会让 DevOps 平台脱离实际，导致没有人会去使用。那么有哪些流程和规范是要提前梳理和统一呢？这里列举几个如下：
-
产品（应用）管理规范：包括版本管理、需求管理的规范等
-
项目管理规范：包括团队的角色构成、过程工作流模板（Agile,CMMI,Scrum）、计划 / 任务管理规范等
-
开发和编译规范：包括代码开发规范（分支主干的使用）、代码提交规范、构建规范（触发策略，是否需要代码提交时构建等）、介质管理规范等
-
部署相关的流程和规范：比如部署架构的规范，环境的管理规范、软硬件资产管理规范等...
Step 2 总结自身的痛点和需求，规划建设路线图（MVP）
完整的 DevOps 平台是个很庞大的体系，如果全都靠自己建设的话，很显然不可能短时间建设完成，那么就要结合自身的痛点，从痛点入手，认清自己最迫切的需求，规划出 DevOps 平台的建设路线图。基于 MVP（ ）的理念，一步步有序的推 Minimum Viable Product进整个平台建设。假如自己的企业目前主要的瓶颈在于如何提升研发效率，那么就可以从统一开发平台、打通持续集成作为切入点。如果目前的主要问题是软件交付速度太慢，那么可以优先考虑持续集成、自动化部署、自动化测试、交付流水线的建设。
Step 3 从组织、技术、流程、文化四个维度持续优化与改进
DevOps 的实施和企业的组织、技术、流程、文化紧密结合，根据我们的经验，在企业中，技术方面的实践最容易在团队中实践，流程次之，组织的优化与变革则是最为困难的。很多时候，不是技术上打不通整个生命周期，而是一些客观的因素导致无法打通各个部门。
我们建议，在实践的过程中，由易入难，持续优化和改进。
在建设 DevOps 平台中，有一些关键点是不得不注意的，简单列举几点：
-
如何支持异构环境、异构应用自动化部署？
企业的应用类型多样，纯前端应用（通过 nginx 等运行），传统 war 包（通过 tomcat 等应用服务器运行），springboot 应用（fatjar 包直接运行）、android 应用、IOS 应用等等，运行环境复杂的要同时支持物理机、虚拟机、容器云。如何做到异构环境、异构应用的部署支撑，并且考虑到后续的可扩展性，对于平台架构的设计是有一定要求的，这个会在后面的部署架构的章节中详细介绍。
-
如何打通工具链的集成？
其实大部分企业，现状都是在软件研发生命周期各个环节，已经有了一批的工具，只是这些没有串联起来，如果是小工具随便用用还好，但是如果是一些用的比较根深蒂固的，可能就不是那么好替换了，方案会更加倾向于集成。集成除了技术因素外，还必须要想清楚哪些工具去集成，哪些不集成。集成到什么程度，比如针对于底层的 IaaS 平台或者容器云平台，我们就只是进行接口调用，而并非功能的接管。对于 Jenkins 这种敏感资源，更倾向于把整个 Jenkins 封装起来，不对外进行暴露。
-
如何与现有的企业流程紧密结合？
不同企业有着不同的流程和规范，以持续交付流水线为例，可以是构建、SIT 部署、SIT 测试、提测、UAT 部署、UAT 测试、LAB 部署、LAB 测试、预发演练、生产部署等环节构成的一个大流程，也有会拆分成集测流程（开发过程中不断运行）、发布流程（从提测开始，UAT 和 LAB 可以是并行的）两个流程，当然也有可能流程和这完全不一样。这也就对 DevOps 平台的建设提出了要求，如何和现有的实际流程紧密结合。
除此之外，还有一些问题也是要考虑进去的，如何快速支持流程使用过程中的一些微调（如环节的配置字段属性等）？如何做到流程手工和自动执行的自定义？如何让 buildNumber 贯穿整个流程，让后续环境部署的介质对应的是哪个 buildNumber 有迹可循？如何直观的查看交付？当做到这些的时候，才能让整个交付 流程目前到了哪个环节、每个环节的状态是什么样的？如何以环境为视角，看到该环境下正在运行哪些应用流水线真正的实现价值。关于这一部分我们的设计同样在后面的持续交付流水线架构章节中进行详细介绍。
-
如何支撑企业 IT 精益运营？
精益运营的基础是度量，度量的三大维度：指标、执行监控 、预测。首先是明确指标和执行监控，基于软件全生命周期的度量过程中企 执行监控业遇到的最大困难莫过于拿不到完整的数据，各个部门、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。当 DevOps 平台能打通企业的软件生产全生命周期时，数据的割裂性问题自然也就不存在。当然，度量不仅仅是事后的统计分析，更应该提供过程监控的能力，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug 燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。
