持续交付和持续集成(7.25)

注：图片来源于网络

最近我的博客谈下半年产品规划，研发过程改进和DevOps持续交付的文章比较多，而下半年有一个重点还是我们SOA管控产品的研发过程改进和持续交付能力提升。在产品已经上线后，后续主要是需求变更优化，小版本规划，版本的发布上线和日常运维。而这块刚好涉及到核心的三方面内容。

1. 研发管理：需求管理开发，小版本规划，计划任务，开发测试，缺陷管理，配置管理，版本发布

2. 持续交付：基于DevOps为基础，覆盖编译，构建，单元测试代码检查，部署，环境迁移全过程

3. 运维监控：上线后的日常运维监控，运维自动化，运维持续优化改进

而里面将涉及到两个关键工具， 其一就是禅道的研发管理平台，其二就是我们自主研发的DevOps支撑平台，同时两者相互协调和配合 。由于本身大项目处于异地协同状态，这些内容都需要考虑进行云化SaaS部署，方便多团队异地沟通协同。

在7月19日自己写了研发过程管理改进的一些关键内容，下面基于管控平台这个系统研发来讲，对相关研发管理改进思路，切换到DevOps支撑平台做进一步思考。

禅道管理重点：需求，版本，计划，任务，缺陷

整理需求规范书文档，包括新增加需求和变更需求

在禅道上面录入具体的需求变更功能点，同样要区分清楚具体是新增需求还是优化需求

建立产品，项目版本，并确定每个项目版本的开始和结束时间

对需求进行版本规划，确定最近一个项目版本要做哪些需求功能点

项目版本里面应该包括需求，开发，测试等关键工作任务项

在开发完成后在禅道里面提交Bug缺陷，提交的缺陷要对应到具体的产品版本上

对当前的管控平台 进行DevOps平台迁移，容器化部署相关改造，其中最主要的是要编写相关的容器化部署脚本，配置文件修改脚本等 。对应WebLogic中间件由于比较大，本身也要进一步确认容器支撑是否有问题。在前期对应管控部署包不需要进行拆分，仅打一个部署包。

DevOps管理重点：产品，项目，编译，构建，部署流水线，环境，环境迁移，自动化测试

在DevOps平台单独创建一个分组，包括多个项目，管控为一个独立项目，自研ESB一个独立项目

在公有云准备两套环境，一套是开发测试环境，一套是UAT测试环境。

需要配置公有云环境的配置管理库

在公司本地环境的配置库需要通过脚本将代码同步到公有云环境配置库(是否可优化）

开发人员在本地进行编译和自测，无问题后check in代码并更新需求或Bug状态

增加代码规范性，代码安全静态检查工具和静态检查

由测试人员进行配置库同步，并触发部署流水线进行自动化部署

增加部署完成后的自动化单元测试，自动进行页面级功能测试

部署完成后测试人员在开发测试环境进行测试，并提交Bug，直到所有问题解决完成

测试全部完成结束后测试人员对配置库和镜像文件进行基线化

基线完成的版本需要支持能够从开发测试环境迁移部署到UAT测试环境，版本是同一个版本

部署到UAT环境后，外部人员可以在UAT环境进行UAT测试和功能验证

公有云两套测试环境，数据库可以采用同一套数据库，但是要有数据库脚本更新处理

对于形成的UAT环境，本身也可以作为我们后续给客户使用的演示环境

在UAT测试完成后，可以考虑准备发布到客户方测试环境和生产环境，在环境发布的时候需要准备需求变更文档，小版本测试报告和测试总结，版本发布申请单，部署包版本和镜像，数据库结构更新脚本，数据初始化增量脚本等。由于客户方环境没有进行DevOps持续交付，因此版本发布还要有详细的在版本发布出现问题后的手工版本回退方式说明。

整个过程优化了哪些地方？

感觉仅仅是减少了在公有云部署一套新环境的人员投入和时间，由于我们自己环境和客户甲方环境本身就是分离的，实际上无法形成持续集成交付的DEV-》SIT-》UAT-》生产的环境迁移链。其次就是能够将代码静态检查，单元测试相关工作自动化。注意需要提供的不是镜像，而是版本部署包的提取功能。提取的部署包和部署脚本可以发布到客户现场。

对于DevOps支撑平台和禅道研发项目管理平台，两个平台的协同实际上做好整个持续交付的关键，初步思考是研发过程管理数据录入反馈仍然是在禅道项目中完成，由禅道项目提供查询接口服务供DevOps平台使用，方便进行最基础的研发效能数据度量。包括需求，代码，缺陷，构建，发布等关键KPI指标的分析。

注意我们本质还是要解决的是研发，配置，测试，运维之间的高效协同问题，只有协同高效了才能够完成软件产品和版本交付的自动化和可持续化。

对于研发过程管理平台和DevOps平台协同，后续需要专门出一个协同图。