一、背景概述
（一）产品背景
1.互联网+的需要
在信息越来越繁杂的互联网时代，公司所运行的项目越来越多，项目相关服务繁多，服务之间存在复杂的依赖关系，运维与管理任务越来越繁重，手工交付需要花费很多的人力与时间，且安全性和时效性均无法保证。对于多资源型分布/分离式部署项目，Udeployer应运而生。
2.随着企业对版本上线质量和速度的要求越来越高，敏捷开发、Devops的接受度越来越高
传统的交付方式因为项目之间缺少依赖、环境不一致、版本不一致、人为操作失误等情况使得项目交付过程中问题不断，而互联网企业发展节奏快、版本发布频率高，上线出故障影响面广、影响度高，因而企业对于敏捷开发、持续集成、自动发布都有强烈的需求。
（二）产品定义
Udeployer是一套完整的持续交付生态系统，在交付过程的每一个步骤都是可视化、自动化的，可以带来包括效能在内的显著的好处，同时也改进了软件的总体质量。Udeployer集合了SVN、Jenkins、swarm、docker、registry等工具，在跨网段、跨内外网等方面可以完美兼容。Udeployer提供项目配置中心，抽象公共配置，项目配置灵活装配。在整个版本交付生命周期推荐使用Udeployer，能够把人为的干预最小化、节省各环节等待时间，使得交付的流程更清晰化，一旦把人的干预去掉，质量就更加可预测，会变得更好。
（三）产品目标
- 1. 构建环境依赖和应用依赖，快速实现多点部署并实现横向部署；
- 2. 实现从代码变更到代码构建，镜像构建和应用部署的全流程自动化；
- 3. 保障项目交付过程中环境的一致性与连贯性，让交付的不仅是代码，还有基于不可变架构的运行环境；
- 4. 持续反馈，随时随时随地构建、随时随地获取回馈信息，让每次集成或交付，都会第一时间将结果实时反馈；
- 5. 减少人工操作，避免开发与测试在人工操作上的失误。
- 二、产品介绍
（一）产品理念
（二）系统拓扑图
（三）系统业务构架描述
（四）系统功能介绍
系统功能主要分为三个层面：源码交付层、版本发布层、容器管理层。
（1）源码交付层
1.1 源码交付层实现对版本的管理。
将SVN版本号与业务版本号一一对应，通过SVN版本号记录业务版本号，包括新版本的创建、多版本的演变过程、多版本逻辑的相对独立、多版本的映射关系等。
1.2 源码交付层通过合并主干、创建分支、版本归档、版本回滚功能实现对源码路径的管理，保证不同版本源码的一致性。
（2）版本交付层
版本交付层通过项目管理、任务管理、工作流管理功能实现持续集成、自动部署、一键发布。
项目管理主要实现版本交付所需要的准备数据的创建与管理，包括项目列表、应用列表、数据库列表、部署模板、邮件模板、配置模板等基础数据的创建；
任务管理主要是实现任务的创建与管理，包括自动化部署、Jenkins构建、重启应用、关闭应用、自动触发邮件发送、分发命令、日志查询、SQl脚本执行等任务；
工作流管理主要实现对任务工作流程的装配与管理。用户根据实际场景需求，通过自定义工作流模板，将任务单个或多次装配到流程中，定义成模板，实现一键或批量执行多个任务。
（3）容器交付层
容器交付层主要通过对集群、节点、容器、镜像仓库的创建与管理，提供全流程标准化的主机管理、应用持续集成、镜像构建、部署管理、容器运维、主机及容器监控服务，实现公有和私有集群的容器化管理，确保不同环境的容器一致性，统一不同环境的依赖关系。
Swarm集群主要是实现集群的创建与管理。用来管理docker集群，可进行节点挂载；
节点主要是实现节点的创建与管理，包括节点挂载集群、添加容器；
容器主要是实现对容器的创建与管理，包括选择镜像、挂载节点等；
镜像仓库是集中存放镜像文件的场所，包括公共的与私有的，提供对镜像文件的查询。
（五）产品方案规格
产品方案不同的规格介绍，或者对产品方案技术规格的介绍。
（一）产品第一阶段
将产品功能分为两个部分：服务组件、我的服务。
服务组件主要负责执行服务功能的基础数据的准备工作，完成项目列表、应用列表、数据库列表、部署模板、邮件模板的创建与管理。
我的服务是功能执行模块，包括SVN源码交付、SQL脚本执行、应用部署、分发器、日志查询。SVN源码交付包括合并主干、创建分支、版本归档、版本回滚、版本发布操作记录功能，实现一站式全生命周期的管理，同时让所有记录都有迹可循，便于跟踪记录。
（二）产品第二阶段
实现配置中心，将配置文件统一集中管理。对于企业用户而言，把不同环境的配置，写到同一个配置文件中，是极其不安全的，是一个非常危险的动作。为解决这一安全隐患，交付系统采用集中式的配置管理系统，将不同环境的配置严格区分地存放。将配置文件按照类型区分为公共配置文件、项目配置文件。公共配置文件可保存为模板，多次循环使用，解决了多次创建的烦恼。通过文件目标路径维度将公共配置文件与项目配置文件进行存放管理。通过路径快速定位到具体的文件，更具时效性、可操作性、安全性。
（三）产品第三阶段
随着公司业务的不断发展壮大，体系越来越多，需要运维的工程也越来越多。如何快速、安全、稳定的交付功能，投入到生产中式企业必须解决的一个问题。交付系统通过工作流的方式，用户可以将每个工程所需要执行的任务装配成工作流，保存为模板，实现一键执行及批量执行。支持同一任务的不同环节装配、多次装配、不同环境、多场景的工作流创建。这样不仅减少了浪费，提高开发和交付过程的效率，还可以使软件随时处于生产就绪状态，以便可以随时实现部署。
三、应用场景
（一）应用模式
（1）单分支开发模式
确定基线、拉分支、合主干、项目发布、版本归档、持续交付
（2）多分支开发模式
确定基线、拉（特性）分支、同步/回滚/合主干、项目发布、版本归档、持续交付
（3）一站式服务模式
（4）分布式服务模式
（二）应用流程
多分支开发模式
1.1 确定基线
SVN-Trunk：工程Demo – 特性开发 – 稳定版本
1.2 拉分支
分支来源于稳定主干，用于新功能的实现。稳定主干均需符合以下条件：
（1） 版本已发布生产环境；
（2） 版本 完成版本归档。
1.3 合并主干
由提测分支合并，用于功能测试、测试环境、预发布环境、生产环境的运行。
合并主干需具备前置条件：提测邮件。提测邮件需具备以下六要素：
项目名称、版本号、分支路径、脚本路径、部署手册、功能边界
（1） 直接合并主干
提测版本号末位-1与当前主干版本号一致。
（2）先同步该主干，再合并主干
2.1 提测版本号末位-1与当前主干版本号不一致，且其他分支有归档记录；
2.2 找到最近一次归档的版本号，同步归档的版本号，再合并主干。
（3）先回滚上一版本，再合并主干
3.1 提测版本号末位-1与当前主干版本号不一致，其他分支无归档记录，提测版本号末位-1在历史版本中存在；
3.2 需找到主干版本号末位-1的主干，先回滚到上一版本，再合并主干。
（4）先回滚分支对应主干，再合并主干
4.1 提测版本号末位-1与当前主干版本号不一致，其他分支无归档记录，提测版本号末位-1在历史版本中不存在；
4.2需找到对应的拉分支时主干，先回滚到对应主干，再合并主干。
1.4 项目发布
（1）持续集成
Jenkins是将代码进行统一的编译打包、还可以放到tomcat容器中进行发布。通过配置，将以前：编译、打包、上传、部署到Tomcat中的过程交由Jenkins，Jenkins通过给定的代码地址URL，将代码拉取到其“宿主服务器”（就是Jenkins的安装位置），进行编译、打包和发布到容器中。在Jenkins的宿主服务器中必须要有可以进行：代码clone（Git）、代码编译（Maven）、代码运行（Tomcat）的基本环境。
（2）持续部署
Udeployer集合了Jenkins、swarm、docker等工具，在跨网段、跨内外网等方面可以灵活配置。在整个版本交付生命周期（包括部署在内）推荐使用Udeployer，能够把人为的干预最小化、节省各环节等待时间，使得交付的流程更清晰化。一旦把人的干预去掉，质量就更加可预测，会变得更好。
四、产品特性介绍
（一）产品特性
l 一站式源码生命周期管理
l 一站式版本生命周期管理
l 一站式容器生命周期管理
（二）应用特性
l 实现线上运维模式；
l 开发 运维 开发的闭环；
l 实现从源码到服务的完整闭环；
l 快速迭代，运维前置嵌入；
l 统一的环境，灰度发布，快速试错/回滚；
l 实现版本追溯并且持续反馈；
（三）系统特性
l 底层服务由Python开发并对外暴露接口，实现对SVN、Jenkins、docker等终端服务调用；
l Web端由Java开发，实现封装Python接口渲染到浏览器并实现权限管理；
l Java、Python基于docker容器开发部署，易扩展，易迁移，实现打包就走。
五、技术实现
（一）相关技术
l API接口开发规范
l Jenkins底层接口调用
l SVN多分支并行方案
l Docker、swarm容器技术
l WebSocket消息实时交互。
六、运维实施