如何走出源码管理的阴影？
本是是工作了7个月3天的应届毕业生，主要负责数据库维护，源码开发到测试、正式发布入库的中间环节，由于业务知识的缺乏，编码能力一般，基本是在很原始的管理的模式下做些纯手工的操作.....
虽然从最开始的手工编写SQL同步管理各种数据库，慢慢的学会用OSQL命令行批处理，学会用PowerDeginer跟MSSQL自动生成规范脚本，学会数据库脚本的持续集成，学习的热情不但没好转，随之而来的困难也开始重重。因为我认识到自动化工具的重要性，经理说过数据库不是尽量少错，而是不能错，每次我人工干预数据库持续开发的时候我就总会不停的停下来对比表结构，对比表数据，用PD刷数据库来对比，因为怕错。
允许我前面说的这些看来很罗嗦的话，后面源码管理的正是我在这种心情下写出来的。源码管理对我来说完全是新名词，我看到公司的开发人员从开始的VSS迁移到SVN，工具是先进了，但是方式依然老套，SVN唯一发挥的作用可能就是可以更多的允许开发人员犯错了。简单说下我们源码管理的流程， 因为系统是在MVC+COMMAND模式下开发的，基本框架包含编码的通用功能，数据持久化采取PD生成的DAO对象映射，数据变化采用的DataSet大部分方法也被封装到DAO中，代码看来还是写的非常规范的。
但是事实并非如此，功能点尽量的被分离成简单的单个文件，耦合的地方大都通过二次框架提供接口，或者在BRIN业务逻辑层提供BROUT调用接口，我之所以说这些，是想说出后面的悲剧。我们做的是企业ERP项目，规模还是比较大的，技术上也是过的去，可是让人不忍受的是非常纠结的代码发布。SVN提供开发人员共享彼此的更改，要发布版本时，先是开发人员提供提交的代码清单，也就是文件列表。我就负责按照清单，从SVN服务器获取最新的文件，复制到之前的测试版本中合并，通过装订打包工具，将DLL文件转换成二进制流写入到自定义文件中，每个子系统一个，最终通过部署工具发布到WebSerice应用服务器上，提供给所有的客户端下载。
大家可能觉得这个过程很平常，我列出了以下几点：
1. 首先由于业务需求变动比较大，开发人员流动大，大伙加班加点，频繁的修改代码，如果没事先说清楚，冲掉对方代码很平常
2. 正是这样频繁的修改，需求文档的不完全约束，极其不稳定的开发环境下，我们没有任何的单元测试，只是纯测试人员的界面点击
3. 正是因为开发人员改动频繁，又没有经过自测，我们才想到将开发人员的SVN环境人为的跟测试环境分离，而这个代码管理的中间重要环节就是我通过重复，仔细，小心的查找文件，复制、粘贴完成
4. 再就是那个部署程序，所有的子系统都是一样大，拥有全部的DLL，可以独立运行，为了这个自由、灵活的模式，牺牲的就是一点代码的改动换来的是整个ERP的重新编译、部署、装订，从来没有补丁一说，耗时又没有保障
5. 最后就是产品的基线管理：源码基线，中间产物源码目录压缩包基线，客户端、服务端安装部署文件基线全部都是通过文件备份在SVN里面，这个基线管理的东西又多，每天重复的劳动却没办法简化操作
为什么我拿它跟数据库开发的持续集成一起比较列，因为他们都是影响项目的最重要的2个东西，它们的不稳定换来就是无休止的担心，更是业务频繁变更的绊脚石。作为项目管理，可能我这个拿的小小薪水的人能力实在是有限，这不是我能左右的事情，项目经理忙在数据库设计，业务需求设计，技术组的人忙于ERP系统的消息、通讯、邮件和搜索等的OA整合组件开发，而开发人员早已被淹没在无止境的BUG修改中。
看到这种情形，最让人讽刺就是做企业自动化的人，却在自己项目中看不到半点自动化控制。开发人员每改个东西要写EXCEL文档，他们烦；测试人员总是埋怨版本发不出来的有问题，因为问题总是出现在SVN获取不到最新，有人没签入，装订工具异常，我看太多的文件列表的时候遗落等；经理等一个版本发布出来等的纠结，一个小时，二个小时的过去；实施人员不断重复，在重复的点击相同的功能点，因为随时他们又会出现错误.....................
如果说软件开发时最严谨的工程，那我们太需要软件工程中的质量管理，我也只是想在这种已经极其不规范的情况下，以为自己可能做到的事情去改善质量。我希望看到我这篇文章的大佬们，能提供一些简单、实用，最好有范例和文档的自动化管理工具，能对我起动启发的经验之谈，或者提供比较合适的问题解决路径和书籍之类。
说的比较多，可能有的人都觉得我说的没重心，我只希望一点小东西，一个小经验，一种小工具都能给我带来帮助，如果有跟我一样陷入源码管理阴影的人，能一起走出来。。。本文长期关注，上班期间一有时间就会多尝试，我也会将它们整理出来，给所有跟我一样的人分享。。。。。。。
谢谢~~~
[解决办法]
看看《敏捷开发的艺术》也许会有帮助。
