新增功能：
逻辑与业务分离，完美实现逻辑与业务分离，业务实现统一shell脚本开发，由框架统一调用。
并发多线程部署，不管多少台服务器，多少个服务，同时发起线程进行更新、部署、启动。
提高list规则文件DIY程度，减少新增服务带来的修改代码，实现扫描list自动化安装部署。（配置、与监控属于业务范围，还需手动修改。）
完善回滚机制，可根据时间段进行回滚，实现即时回滚即时使用。
1 引言
自动化部署与统一安装升级，适用于多资源型分布/分离式部署项目。
随着服务/业务的越来越多，配置文件更是眼花缭乱，每次不知道因为部署/安装问题浪费多少时间，更不知道因为配置问题出过多少问题。多台服务器来回切换，如果服务需要依赖，启动更是问题。
怎么实现自动化安装升级，一键执行统一安装。
适用于多资源型分布式部署项目，随着服务的越来越多，配置文件更是眼花缭乱，每次不知道因为部署问题浪费多少时间，更不知道因为配置问题出过多少问题。多台服务器来回切换，如果服务需要依赖，启动更是问题。
1.1 目的
统一安装、批量部署、统一监控。
1.2 范围
本项目使用范围包括：
- 基于多资源型开发项目
- 项目相关服务繁多
- 服务多依赖关系
1.3 读者
本需求规格说明书的阅读者或其他文档干系人有平台总监、产品经理、项目总监、项目经理、开发人员、测试人员、运维人员、用户体验设计人员等。
2 项目总体描述
2.1 系统总体功能框架
执行统一安装前，首先备份上一轮项目并提取涉及配置文件，再是检查SVN更新版本，确认无误后执行统一安装。
实现一键执行统一安装,执行完毕展示服务进程及相关版本。
2.2 系统功能列表
编号 | 模块 | 功能 | 说明 |
unifyDeploy_0.1 | Exec | 建立信任、初始命令 | 初始 |
unifyDeploy_0.2 | Tools | 服务介入List规则 | 扫描提供服务列表，获取配置信息 |
unifyDeploy_0.3 | Conf | 配置文件处理优化展示 | 自动生成 |
unifyDeploy_0.4 | Bin | 执行工具 | 提供总执行与单一执行 |
unifyDeploy_0.5 | New | 存放修改后配置文件 | 与bak保留文件成反比 |
unifyDeploy_0.6 | Bak | 存放原始配置文件 | 便于问题分析 |
unifyDeploy_0.7 | Temp | 存放临时文件 | 临时文件将及时删除无任何冗积 |
unifyDeploy_0.8 | Workapp | 存放安装包 | 上传安装包 |
unifyDeploy_0.9 | Workbak | 备份安装包 | 统一回滚 |
3 功能描述
3.1 获取配置文件
通过本系统统一安装部署非常简单，只需用户根据list模版提供服务列表，其他无需操作。服务列表如下：
名词解释：
server ：服务名称 ip ：服务器ip指向 path ：部署路径指向 config ：配置项 cfpath：配置路径
执行脚本，“conf”目录自动生成用户所需修改配置文件，配置文件是通过处理筛选后生成，所以一个服务不管需要配置多少文件，这里只生成一个，方便修改与管理。配置文件沿用上一轮版本配置文件，在新一轮版本没有新增配置项情况，无需修改跳过此步。
3.2 自动化统一安装部署
自动化统一安装部署，包括：主机信任、SVN安装包下载、上传解压安装包、同步配置、上一轮安装备份、启动服务、监控服务等。
list.sh init.sh pass.war startup.sh syn.sh exec.sh thread.py
部署支持统一安装于分布式安装，每个脚本可以拆分开任意组合使用，比如：
1) 一套新环境中还未部署服务，只需调整上传安装包脚本顺序，先上传安装包后，后续操作正常执行。
2) 迭代更新，功能稍作修改，原配置项无需修改，也只需调整上传安装包包脚本顺序，先获取原有配置，再上传更新安装包包，后续操作正常执行。
3.3 与Ansible优缺点对比
优点：
1) 框架开源，业务脚本基于shell开发，不像Ansible封装的那么严重，只能按照他的格式去写
2）将一个服务下的多个配置文件处理成一个配置模板，与Ansible相比更加的方便修改与检查
3）支持更多的DIY功能，更好的实现监控进程、检查版本等
4）可根据时间段进行回滚，实现即时回滚即时使用
5）不仅适用于更新部署同样适用于第一次部署
缺点：
1）Ansible商业化要久，更多人在用
自动化部署与统一安装升级 - 类ansible工具 unifyDeploy0.3版本发布 （更新时间2014-12-24）