1.自动化代码部署概述
将源代码变成一个能运行的软件系统通常是一个复杂的过程，包括编译，文件搬移，加载数据库模式等等。但其中大多数任务都是可以自动化的，并且也应该被自动化。代码部署是软件创建过程中又一个适合实现自动化的方面,通过自动化部署，可获得一个准确、可重复、安全可靠的流程，其中好处颇多,如更高的准确性、更快的速度和更好的控制,回滚等。
7 种有益的部署方法
Binary Integrity，确保全部目标环境使用相同的工件。
Disposable Container，使目标环境处于已知状态，以减少部署错误。
Remote Deployment，确保部署可以从一个集中化的机器或集群与多台机器交互。
Database Upgrades，提供一个集中管理的、脚本化流程，以便将增量更改应用到数据库。
Deployment Test，根据最近的部署，使用部署前和部署后检查，确认应用程序按预期运行。
Environment Rollback，如果部署失败，回滚应用程序和数据库更改。
Protected Files，控制对构建系统使用的某些文件的访问。
自动化部署模式(图)
| 名称 | 内容 | 模式 |
| Repository | 把所有文件提交给一个版本控制存储库 | 所有文件都被提交给版本控制存储库 — 在部署上下文中，这是指所有配置文件和工具 |
| Scripted Deployment | 用脚本执行所有部署流程 | 在脚本中编写所有部署流程 |
| Single Command | 通过单一命令运行部署 | 部署者或无头流程只需输入单一命令，即可为用户生成有效的软件 |
| Tokenize Configuration | 把可变信息注入配置文件 | 把标记化的值输入配置文件，然后在 Scripted Deployment 期间根据 Repository 中的 Externalized Configuration 属性替换它们 |
| Externalize Configuration | 提取所有与环境相关的属性 | 把所有可变值从应用程序配置转移到构建时属性中 |
| Headless Execution | 通过无头执行减少麻烦 | 安全地与多台计算机进行交互，而不需要输入任何命令 |
| Template Verifier | 检查在不同的环境中属性是否相同 | 创建一个模板文件，所有目标环境属性都基于这个文件 |
| Unified Deployment | 同时在多个目标环境中执行部署 | 创建能够在不同的平台和目标环境中运行的单一部署脚本 |
传统代码部署方法
纯手工scp
纯手工登陆git pull,svn update
纯手工xftp往上拉
开发给打一个压缩包，rz上去，解压
缺点
全程运维参与，占用大量时间
上线速度慢
人为失误多，管理混乱
回滚慢，不及时
自动化代码部署解决了以上的痛点!
2.环境的规划
1.开发环境：
开发者本地自己的环境，运维需要设置的开发环境(大家共用的服务。例如：开发数据库mysql，其它:redis,Memcached)
2.测试环境：
功能测试环境、性能测试环境和自动化测试环境
3.预生产环境：
生产环境集群中的某一个节点担任
预生产环境产生的原因：
数据库不一致：测试环境和生产环境数据库肯定是不一样的
使用生产环境的联高接口
4.生产环境：
直接对用户提供服务的环境
3.设计一套生产自动化部署系统
1.规划
举例:
1).1个集群中有10个节点
2).实现一键部署10个节点
3).一键回滚到任意版本
4).一键回滚到上个版本
2.实现
部署:
1.代码存放在哪里
svn、git
2.获取什么版本代码？
直接拉取某个分支
svn:指定版本号
git:指定分支
3.差异解决
配置文件未必一样：crontab.xml 预生产节点
代码仓库和实际位置的差异：配置文件是否放在代码仓库中。Config.sample配置文件只在部署上有，单独的项目
4.如何更新
Java Tomcat需要重启
5.测试
6.串行和并行
分组部署
7.执行
shell ./执行
web界面
流程:
回滚:
3.总结和扩展（PDCA）
4.在生产环境中应用(最重要)
参考:http://www.ibm.com/developerworks/cn/java/j-ap/
