svn的多项目并行源码管理与自动发布思考

       在上家公司做运维时，接触到了代码管理和版本的发布工作。当时的公司刚成立，IT人员非常的少，总共五个人（包括UI设计，开发，运维）带着20个左右的外包。回想当时真是我工作7年中最痛苦的日子。

       当时开发速度非常快，几乎每天都有版本上线发布，开发把svn的代码管理，编译，测试环境部署都丢给了运维。开始是每个开发把修改代码提交到svn，通过邮件告知修改了哪些内容，然后运维从svn上逐个取到本地后编译。整个svn上的代码非常不稳定，我只能尽量的保证自己本地环境是稳定的，以便用来发布。后来根据根据开发提供的列表通过写dos命令抽取后编译，这样快速了一点，再后来随着对svn的了解自己写了shell脚本通过svn的钩子记录开发提供的代码文件，自动从svn取下后通过ant编译。虽然简单了很多，但是经常出现要上线的代码与不上线的代码混合到一起，或者生产出现了紧急问题需要修复时找不到与生产环境匹配的代码库，只能取单个文件修改后单个更新。由于当时自己不做开发，未能深入了解到svn的使用，反复思考还是未能找到最好的解决方式。最近重新去网上看了下svn的代码管理和自动发布系统的思想后，清楚了当时存在的问题和解决方式。

当时的错误点：

1、当时发布版本太随意，无任何版本计划

2、只依靠svn对版本的管理，未能考虑开发提交规范

3、对应用并行开发，未能利用svn的主干、分值、版本库概念

4、通过复杂易错的增量发布，未能采用打包全量发布

    对于互联网应用系统失效性要求高，版本发布频繁，发布过程尽量对用户无影响。使用传统应用中的手工打包，手工发布已经无法满足需要。目前大家都在推出自动部署概念。但是在自动部署建设中最难的就是代码的管理工作，如果源代码没有好的管理部署到系统会出现各种问题，例如最烦恼的代码叠加到一起。svn，git虽然是很好的源码管理工具，单并不意味着大家可以随意提交无任何规范。工具只是帮助我们更好的工作，还需要很好的管理规范才能让工作更好的运行。建立自动发布系统个人觉得需要有下面几个方面的完善。

1、对开发需求安排合理的版本计划

2、对多项目并行开发时采用主干，分支，版本库。主干用来发布使用，分支用来并行开发后续版本或大需求使用，版本库保存上线后的版本代码，以便生产出现问题紧急修复时使用。

3、严格的开发需求编号，在钩子中设置主干允许提交的开发需求编号，只允许提交注释为下个版本的代码。始终保持主干是相对稳定的版本。

4、每当版本封板后，tag出一个版本到版本库，同时创建一个最新的分支，然后把下个版本要上线的内容从分支合并或提交到主干。

5、将配置文件、java文件、sql文件分别放到不同的文件夹中。新增配置文件和sql文件在自助发布系统中指定，配置项也在自助部署工具中填写，发布包直接从主干取出后编译打包。

6、每次测试完成封板时由测试负责人点击测试完成后系统将本次要发布的配置文件，配置项，版本包存放到一个指定目录。

7、由版本负责人审核通过后发布人员才能按计划发布版本，在发布版本时对涉及到的生产环境配置文件和部署包进行备份。这样方便上线后的回滚，对于sql的变更如果需要回滚只能由人工操作，不过这方面的回滚操作很少。

在没搞清楚这些问题时怎么思考自动发布总是各种问题缠绕无法解决，相信清楚了这些自己在做自动发布时就很好实现了。