在数字化的转型浪潮中，开发人员的生产力越来越被企业重视，提升团队研发效能、缩短TTM成为了实现企业战略目标的重要措施。企业中的研发团队从每个团队各自试验、探索，逐步整合基础设施、最佳实践、企业规范等，形成企业内部研发平台，为所有团队开放企业核心资源和提供DevOps能力，使研发团队更专注于业务价值的交付。
经过多年的业务能力建设、不同的技术投资和整合，许多传统组织被遗留技术、人员、流程和文化所困扰，这阻碍了企业进行创新和试验。他们看到互联网新玩家冲入行业赛道，并取得指数级增长，蚕食其耕耘多年的市场份额。这些新玩家没有负担，他们更快、更精益、更勇于尝试，并采用平台化思维。
在与这些企业或组织的合作经验中，我们观察到他们的平台化战略转型往往会经历三个演进过程，首先他们使用成熟的工具链提升研发速率，紧接着整合企业资源，构建研发平台实现效能度量和持续改进，并最终尝试开放技术平台打造共赢生态。
研发工具链
在一个研发团队运行的早期，由于经验、成本、进度等限制，没有较为成熟的交付体系与研发工具，尤其是规模较小的团队，他们更倾向于选择市面上已有的一些研发工具。不论是FOSS（免费开源软件）还是COTS（商业现成产品），总是希望采用一些开箱即用的成熟产品，来提高整个研发交付的效率，尽可能降低研发工具自身复杂度对交付带来的影响。
不论一个团队规模如何，有几类常用的工具会贯穿整个研发与交付流程。我们可以简要的分为这几大类：
项目管理类
在项目协作、需求管理方面，很多团队都采用了Jira，Confluence等Atlassian系工具，或TFS的微软系工具。国内企业常用阿里云效、禅道等。这类工具的功能大而全，能满足绝大多数团队的需求，并且有成熟的售后支持。
此外，还有一些功能较轻量级的管理工具，例如Trello，Mingle，github.pages等，只提供看板维护、文档展示等较为单一的功能，使用时需要在这些工具间来回切换。
研发构建类
越来越多的团队开始实行敏捷开发，为了缩短发布周期，而逐步推动持续集成与持续部署，相应的研发工具也慢慢推广开来。如版本控制工具Git；构建工具Maven，Gradle；CICD工具Jenkins, GoCD, BuildKite, BamBoo等。
代码测试类
由于人工手动测试耗时耗力，容易出错，特别是在上线前的回归测试，往往是重复枯燥的体力劳动，我们倾向于将更多的测试自动化，集成在流水线中。许多团队会在用Gatling，Selenium，Cucumber，Jmeter等测试工具，从安全、性能、UI、业务等角度全面覆盖，并将测试过程自动化。
部署运行类
基础设施维护也是较为繁重的工作，从虚拟化到容器化，再到无服务化，大大减轻了运维的成本和复杂度。如Vagrant，Ansible，Docker，Kubernetes，Istio等工具，近年来被较多采纳并实践。
监控运维类
当软件运行起来后，需要持续地进行监控和维护，其工具也非常丰富，如Prometheus，Logstash，ZipKin，Zabbix等。
还有许多同类型的工具如下图所示。
（图片出处：http://www.jamesbowman.me/post/continuous-delivery-tool-landscape/）
这种研发工具链的模式经常由小团队开始尝试，并以自下而上的方式向其他团队推广，还有一部分企业，会从流程规范的角度入手，以自上而下的方式在企业内部推动实践。
通过工具链快速提升企业研发能力, 其明显的优势是可以快速试错，探索新工具和新交付实践，并以较低成本推动研发进程。同时，在没有工具链研发能力的前提下，将这部分的风险外移到成熟的第三方工具上。
但其劣势也很明显，可以简要描述为以下几点。
团队成员需要有一部分精力来负责第三方工具的搭建与维护，某些较复杂的工具，可能还需要一定的学习成本。如果第三方工具在运行中出现了问题，还可能耽误正常的研发进度。此外，由于研发中的各种数据被分散在了不同的第三方工具中，导致信息流被阻断，研发数据不能在交 付的各个流程与阶段中共享。并且由于工具链的选择相对自由，部分工具不符合公司流程，会导致合规性的问题。再者，不同团队间工具链的实践难以共享，而且由于其灵活性，企业的管理成本也显著提高。最后，随着工具链的推广，一些公司会将这些工具标准化，但这样会一定程度阻碍快速试错，探索新型交付模式等。
研发平台
采用研发工具链在短期内能够快速提升研发效率，但会导致这些工具链的知识和能力存在于少数Team Hero中，使用工具链的成熟度受限于团队中DevOps的经验，一些精英团队中具有的先进实践难以广泛的在企业范围内共享和推广。
为了应对这些问题，企业开始梳理各个研发团队的工作流程、邀请DevOps专家、结合企业安全规范流程，整合为研发平台。
研发平台通常包括持续集成能力、持续交付能力、运维和运营能力以及安全服务。研发平台通常会采用云提供商和传统数据中心提供的能力和服务，并托管、改造或扩展，以使研发团队的开发人员可以方便地使用。目的并不是全新开发一套CI、CD或容器管理产品等重复造轮子，而是弥合企业可以采购到的产品与研发团队真正需要的产品之间的差异。
这些研发平台通常有以下特点：
高效、量身定制的研发流程
开源工具链和商业产品适用对象广，自由度高，但一般仅有有限的几种使用方式能够匹配企业的流程规范。
某大型通讯企业的DevOps平台，为保证其产品质量，在CICD流水线中增加了质量门禁，当开发人员将代码push到代码仓库后，会经过代码静态检查、测试覆盖率、第三方依赖扫描等自动化审查，只有全部通过阈值，才能进入部署环节。
为了符合不同国家数据隐私策略和法律法规，避免开源软件版权陷阱，代码扫描环节加入了对依赖包的版权检查，研发团队需要从企业统一提供的依赖库中获取符合规范的依赖包，而依赖库由专业的团队维护，定期检查和更新。加速各地域政府法律审核流程，降低法务和违规风险。
在应用软件版本发布环节，研发团队需要提交发布计划，设定发布操作的时间窗口，由管理角色确认授权。当进入发布操作的时间窗口后，研发平台会自动生成授权码发送给操作人，在发布新版本中的每一步操作都需要验证该授权码的有效性。
支持多种研发模式
在中大型企业中，不同的业务线、不同的研发团队，面对的业务场景差异较大，业务变化速率也不尽相同，如果以一刀切的方式要求各个团队，则将会限制迭代频繁的团队实践持续交付节奏，或者要求企业稳定的核心业务符合敏捷流程而强制性更新带来可靠性降低的风险。
某银行在其DevOps平台上支持IT双模，对于核心系统依然采用传统开发模式，强调稳定性，涉及客户界面则采用敏捷开发模式，迭代开发的周期可缩短到2-4周，比传统开发方式两到三个月的速度显著提升。研发平台约束研发流程和推广最佳DevOps实践的同时，兼容为特殊业务线的支撑能力。以科技能力构建新型双模，支撑企业复杂业务模式。
兼容特殊业务场景
对于研发通用流程的Web应用服务，可选择的工具链非常丰富。但对于特殊的业务场景例如嵌入式或移动应用，兼具易用性和匹配定制化需求的工具链会比较稀少，由于适用场景局限，开源社区也不愿投入过多精力支持。这样的情况下，企业的研发平台就可以根据企业内部需求，实现该场景下的能力支撑。
与企业现有系统深度集成
企业通过采购和自研拥有大量IT系统，各个IT系统构建和部署方式差异，导致各个维护部门能力参差不齐，部门间协作产生的摩擦越来越多。
各个IT系统生成的数据也掌握在部门内部，集成和共享时会遇到接口不兼容、技术不通用等问题，部门间墙也越来越高。各个团队构建的IT系统风格迥异，用户体验割裂，使用成本上升。
在某车企构建的研发平台中，充分考虑到这些场景，依托平台为企业内部各个部门和团队提供多样的脚手架市场。研发团队可以基于符合业务场景和技术背景的脚手架应用，提供统一的用户体验。使用脚手架模板大大缩短新产品的准备时间，从脚手架的应用情况可以统计到各个部门构建的应用技术类型。
企业内部IT系统，集成平台能力，容易实现SSO，企业员工通过统一的用户身份和认证鉴权体系轻松访问不同业务系统。结合产品的生命周期管理，易于绘制企业内部IT系统的Landscape，实现统筹规划与价值投资。
统一采集度量数据，持续分析、持续改进
在传统企业中，管理者想要了解各个研发团队的交付效能，遇到的首要问题便是各个团队无法提供统一的数据格式。不同团队研发实践方式，产生的度量数据维度混乱，难以集成，更无法分析。甚至会遇到有些团队投机取巧地研发“数据上报系统”，能够自由控制或伪造度量数据。
针对以上痛点，企业可以基于研发平台提供成熟的交付实践的同时，提供统一的度量数据采集能力，沉淀企业的数据资产。为各个研发团队提供自身交付效能的参考数据，协助识别研发速率短板。同时通过灵活配置分析和统计维度，为不同管理角色的数据展示Dashboard。
研发平台的价值远不止以上几点，企业基于研发平台优势，快速验证新业务和将新产品推向市场，实现加速转型和适应市场变化。管理者在看到企业取得数字化转型的成就时，需要保持危机意识和风险识别能力，不断思考一个问题：企业构建的研发平台难道就是最终形态？
开放技术平台
随着研发平台的功能改善与效率提升，得以在企业内部逐步推广，各个部门及团队都会将研发平台作为自己产品研发的支撑平台，企业内部整体的研发交付成熟度得到了显著提升。但当产品数量快速增加，各个产品的交付及运营的流程相对独立，难免会有一部分应用会出现传统研发平台常见的以下几类问题：
功能或模块相对重复
由于部门墙的存在，研发交付的产品会散落在不同组织与部门内部，并且没有统一的机制去审核所研发的产品是否在企业内已经有类似，或功能有重叠，因此会导致重复开发，造成人力和基础设施资源的浪费。这种缺少统一的开发规范与管控的模式，同样也会导致业务系统常见的身份认证管理、日志管理、行为审计等子模块在不同产品间有大量重复。
内部系统信息流未打通
对于企业内部使用的系统来说，统一互通且易用是非常重要的，但在研发平台的模式下，其数据是相互独立的，信息流并未打通，使用者需要切换多次来使用不同系统。并且，数据的隔离也导致各个业务系统不能共享信息，不光没有集中的数据管理服务，也难以从综合的角度挖掘出新的价值。此外，由于没有统一的设计思路，各个内部系统的使用习惯也不太相同，对用户造成一定困扰。
各个系统的合规性不高
虽然研发平台内建了标准的开发流程和效能度量，但在更细致的如安全认证，行为审计，API设计，基础设施稳定性等方面，不同部门会独立开发、其平台设计规范不同，技术标准也不同，而且水平和规范程度会参差不齐，较难达到较高水平且统一的合规性标准。
平台能力有时滞后于需求
强势业务部门或优秀实践团队的一些诉求可能会超出研发平台提供的能力，无法快速提供。这些团队会较长时间的受限于研发平台的技术实践、流程管控，无法快速获取到更新更好的实践。而且在研发平台向更大范围推广过程中，也会遇到不同组织的交付流程、法律法规等差异，在提供支持方面同样存在一定滞后性。同时，由于企业内部的组织架构一定程度上存在部门墙，不同业务系统由各个部门独立开发，没有技术与功能的共享机制，导致平台能力不能快速迭代演进。
因此，为了解决以上问题，研发平台将会慢慢演化成一种具备开放能力的平台，也就是开放技术平台。它是指在平等的基础上，由多主体共同建立的、资源共享的、能够实现多方共赢的、全面开放的一种新的企业级技术生态系统。通过一定程度的约束来规范产品的研发与发布，形成自组织的生态系统，达到开放共建的最终目的。
其特点主要有以下几点：
能力产品化, 促进企业内技术产品快速孵化
各个团队拥有不同的技术能力与业务能力，而这部分能力往往隐藏在各种工作流程与实践中，我们希望可以将这些能力转化为可以直接被复用的成果，即产品化。依托开放技术平台，就能够让技术产品快速孵化，不断迭代，最终共享在整个企业内部。从而减少类似功能的重复，节约企业的人力和基础设施消耗。
开放社区化, 吸引合作伙伴共同分享技术能力
依靠开放平台的优质服务，吸引其他团队分享自己的技术能力，打破单一部门的能力局限，逐渐形成社区文化，加强企业内部技术交流，让更好的实践在企业内传播，做到优势互补，提升各个团队的能力与产品质量。同时，这种共享的机制有利于产品向企业内更大范围推广，依靠各地区的开发者，可以让产品更加适用于各地情况。
产品标准化, 通过开放平台构建高质量的合规产品
开放技术平台可以从身份认证与数据权限鉴权、服务与参数配置、加密与秘钥管理、敏感信息脱敏还原、产品发布审核流程、统计报表展示与分析等方面对产品进一步规范化和统一化，从而构建出符合标准的易用的高质量产品。
开放技术平台为解决传统研发平台的问题提供了可能，利用开放共享的思想，突破了研发平台能力的瓶颈，是一个普遍的发展趋势，可以让企业在共享、标准、开放等方面，构建起健康的研发生态，促进交付模式的不断演进，从而大幅提升企业效益。
最后
打造企业内部的研发平台或者运营研发开放平台，跟其他产品一样，都需要考虑平台所能创造的商业价值。对于研发团队不同规模的企业，这个过程不是一蹴而就的，企业可以从工具链开始尝试，构建自己的研发平台，逐步演进成技术开放平台。只有在业务价值的驱动和有效的战术执行下，平台才能通过减轻产品开发团队的认知负担并加速组织的创新来取得成功。
文/Thoughtworks党森、Thoughtworks刘钊
原文链接：/research-development-open-platform-tool-chain/
更多精彩洞见，请关注微信公众号Thoughtworks洞见。
如果觉得《研发平台演进：从工具链到开放平台》对你有帮助，请点赞、收藏，并留下你的观点哦！
