有料丨如何实施数字化云平台的集成与交付（PPT）

EAII

元元博士

今天的内容会从：“识别挑战、制定策略、给出方案” 三个维度说起。

数字化云平台MVP的集成与交付工作会受多团队、多技术栈、多领域系统、不同的发布窗口、时间紧等因素的影响。

集成工作必须要去面对这种现实，并给出一种合理的解决方案，保证新一代的MVP顺利的集成和交付。

先前的集成与交付反馈环难以适应现状。开发、测试、运维各环节信息传递的失真会导致集成与交付速度降低。开发在整个集成与交付的过程中所占比例不高，但却承担了主要的责任，如：环境验证、联调、BUG修改等等，这些都很大程度上决定了集成与交付的效率。

数字化云平台采用微服务架构，涉及到多个领域系统的开发、集成与交付。模块化程度越高、层级划分越详细，越会造成更加复杂的配置与集成的工作量，直接导致了交付成本高昂、团队难以协作等问题。

我们需要制定合理的策略与方案应对这类问题。

整个技术团队采用MVP（最小可行产品）原则，最短时间内快速交付产品原型，然后通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。集成工作也遵循MVP原则，以最小可行产品为目标，用户体验至上，对提出的理念与假设设定度量值与方法，通过数据证实并快速调整方向。

FirstApp是我们在完成原型设计以后对我们的设计进行验证的DEMO。我们认为，集成工作应该从FirstApp开始。FirstApp是Devops自己开发自己的源点，它完成了软件配置管理的功能，统一管理了开发、测试、预上线、生产环境的各项配置，这个DEMO应用的目的有三个：

1、验证设计阶段所定义主流程的合理性；

2、手工方式实现主流程，并完成Devops平台中的软件配置管理模块，用于自动化配置管理；

3、各领域系统开发阶段，软件配置管理涉及的步骤实现自动化，并随领域系统的完成，主流程全部实现自动化。

在这一阶段，集成工作主要包括了：编写集成验证方案、制定开发进度跟踪表、搭建持续集成环境、测试用例编写等。

我们根据总体设计，从集成的角度把系统划分为四个层次，其实每个层次代表了一个不同的视角，不同的视角给出不同的测试方法。功能视角的单元测试部分是由各开发组完成，根据每个模块的详细设计给出单元测试用例，每组组长是第一责任人。其余三个维度的集成与验证工作均由集成组负责，系统视角的集成测试根据系统与系统之间的调用关系 1对1进行集成测试，并完成自动化测试用例；从平台视角的全链路测试，根据某一具体业务场景，比如：设计-开发，将各领域系统、接口进行串联，并完成自动化测试用例。

上图描述了单元测试、集成测试、全链路测试、黑盒测试在各层所涉及到的测试对象。根据测试类型不同，测试对象所涉及的侧重点也有所不同。比如：在单元测试过程中就不必太关注页面展现、兼容性；黑盒测试过程中就不必关注缓存、二进制库、容器等。

全面实现自动化是持续集成与持续交付的核心，单元测试、集成测试、全链路测试、黑盒测试一定要做到真正意义的自动化执行。虽然在开始阶段会付出一定的代价与成本，不过"磨刀不误砍柴工"。

我们组建了专业的团队支撑集成与交付，而且团队成员均来自其他四个开发组，这对集成过程中对整个需求、设计、开发的理解会有非常大的促进作用。集成组与四个开发组的人员配比为 1：3。集成组以测试用例驱动开发，各组开发人员所实现的功能逻辑是否满足需求很大程度上取决于测试用例的执行是否通过。与此同时，所有的功能代码、测试用例每天编译执行打包，实现持续迭代。

对于开发团队的分工与职责划分，在项目开始阶段我们就对后续的集成工作进行了考虑。按技术与业务解耦划分开发团队，各组针对各自技术域进行功能开发，与其他开发组边界清晰又互有交集，同时理出系统进程、接口之间关系，定义交互规范，明确依赖。这样一来就非常有助于后续的集成工作。

通过团队与组织的支撑，我们对项目的交付模式也进行了革新。在持续交付过程中，需求以小批量微服务的形式在团队各个角色之间流动，并以较短的周期完成小粒度的频繁发布，频繁发布不仅可以实现敏捷，而且可以快速的通过集成与测试产生反馈，及时调整开发与发布策略。

交付模式革新的关键在于：小、频、快。

这种革新的基础在于平台和自动化工具的支撑，我们从FirstApp（软件配置管理）入手，对Devops所涉及到的能力逐渐完善。从手工到自动化执行，形成了以开发、编译、测试、部署、预发、上线等步骤为核心的软件开发、集成、交付的最小可用版本。开发、测试、运维通过Devops Portal进行有效协同，在此平台之上“自己开发自己”。

在每一个微服务执行编译、打包、部署时，底层使用Docker把任务模块化，然后做成有针对性的Image用来跑所需要的任务，每一个任务的创建工作可以在开发者、测试者本地或远程环境执行。所以，使用Docker之后，集成与交付过程中的各环节边界（功能、用例、接口、环境等）很自然地被定义出来，并可以查看每一步的执行时间、状态。

开发、测试、集成也可以针对任务的需要，为每一个任务定义严格的性能标准，已作为之后迭代的参考基础。

通常持续集成意味着代码被不断地测试，与其他的代码修改进行整合与合并；持续交付意味着不断将带有补丁的代码部署到整个代码库中。对于文档来说，部署就意味着发布，部署文档就意味着需要被别人查阅，各阶段文档描述需要与功能代码相对应。针对这类问题，后面我们会借助一些类似Gerrit的工具来完成文档的持续集成与交付。

最后我们来做一个总结。

数字化云平台的集成与交付需要合理的团队组织分工，技术与业务解耦的方式划分技术团队，集成团队知识、技能覆盖领域要广泛；并借助工具自动化一切，形成闭环反馈模型。

接下来开发、测试、集成团队会全部在异地分散状态下进行工作，我们会通过灰度发布等方式保证平台可以在开发、上线之间平滑过渡，并保证系统稳定；另外我们的研发团队的规模会逐渐地扩大，这对我们现有的组织形式、工具、平台会有哪些新的要求等等这些都是我们需要继续思考的。

关于作者：

臧一超

EAII-企业架构创新研究院 专家委员

现任普元大数据产品线副总，基于微服务的企业架构实践者。十余年IT行业经验，专注于SOA、分布式计算、大数据处理、企业架构设计等领域。曾指导带领技术团队完成航天科工四院协同数据交换平台、上海移动ESB集成平台、华夏人寿服务治理平台等项目的系统实施以及方案撰写。