自动化部署的前提

最近开始负责公司项目工程的打包发布，之前都是在IDE中手动打包，需要发布版本包时费时费力，而且很容易出错，为了提高工作效率（主要是因为懒），开始接触学习自动化部署，一番折腾下来，总结了自动化部署的几个前提。

版本管理

在大多数的公司或者项目中，虽然都使用了SVN/Git进行代码版本管理，但是在实际应用中能够按照规范应用的很少，绝大多数项目中只有一个分支（trunk/master），开发测试、版本发布、生产环境BUG修改以及特殊功能开发都在这一个分支上操作，管理稍微好点的可能会将tag利用起来。
在项目比较小，参与人数较少，需求和BUG修改周期可控的情况下，直接在trunk/master分支上进行操作，完全没有什么问题，最多在某些情况下提交代码比较麻烦，平常看不出问题，但是在多人协作开发，多个业务功能并行开发时，就会很不方便，也不能对发布版本以及BUG修改进行清晰有效的管理，下图展示软件开发过程中各分支切换合并操作。

配置文件管理

开发环境、测试环境和生产环境的文件必须独立可配置，能够根据不同的环境将相应的配置文件打进版本包中。
一般对于电商、互联网项目，生产环境只有一个服务（或者配置完全相同的多个服务），项目中对于配置文件的管理比较方便。但是像一些传统软件行业，产品有一套，然后多个项目实施，配置文件各不相同，在后期版本发布打包的时候就需要考虑配置文件的抽取。

数据库的变更

现在大多数项目的自动化部署，只是将代码的编译以及项目的部署实现了自动化，对于数据库的变更，还是依赖人工处理，我认为真正的自动化部署是要在项目部署完成后同步完成对于数据库的变更，避免人工去执行数据库变更脚本。
在Java项目中可以使用以下工具进行数据库变更管理，如果项目是使用Maven构建，Liquibase和Flyway都是不错的选择，都有Maven插件。
Liquibase
Flyway
Mybatis Migrations
Mybatis Migrations Maven Plugin

总结

其实没有做到上面的三点，做自动化部署一样可以，不过在实现的过程中就会很不方便，也不利于对于代码版本的管理，随着持续集成，出现问题的可能性就比较大。规范之所以被人所推广，就是因为他能够避免掉一些已知的问题，不遵守开发规范甚至没有规范的项目也有很多，项目一样运转，但是背后白白浪费掉了很大的时间和精力，自动化部署的目的还是要解放人力，提高版本发布的稳定性。