（一）上周，manager告诉我，为了便于公司内部对版本进行管理，以后版本实现每日构建。每日构建的意思是，以每几天为一个周期，对版本进行需求提交、程序开发、修改、测试等一系列过程。

软件的版本问题，似乎是所有软件公司的问题，因为版本的混乱导致了很多本来就不该发生的问题。在以前的公司，就出现过这个事情，程序开发完了，也通过测试了，但提交给用户的却还是以往的版本。


现在最常用的配置管理工具，可以实现版本的管理，如VSS、CVS、SVN等。我接触过两个，VSS和SVN，平时用的功能很少，就是ADD、GETVERSION、CHECKOUT和CHECKIN。VSS可能是最常用的工具之一吧，操作简单，易学，但是当代码增多时进行MERGE的时候，就出现了一系列读取速度过慢等问题，SVN呢，可以解决这方面的问题，但是在操作上，不太符合一直以来的使用习惯，总之我是觉得在实用程序上，SVN不如VSS好用，可是功能上却强大的多。

（二）每日构建的周期暂定为五天一个周期，进行程序的版本提交，需求的整理和上一个版本的测试报告的提交。现在手上负责的产品A，应用到了不同的项目中，根据项目的需求又分出不同的项目版本，以A作为主线，其他项目暂且叫做A-1,A-2.....以此类推。

周四，该是版本的提交日，到了下午，跑到开发那边，提醒了一下按时间提交。开发与测试之间似乎总是敌对的，没办法，立场不同，都是为了工作，虽然有的时候增加了部分工作量，但公司规定就是这样，也没办法。

前段时间为了进行产品发布，对A的图标和界面做了调整，单个的图标和界面之前看过，很不错。拿到版本的时候，心想，终于可以不看以前那个灰灰的界面。满怀欣喜的打开后，差点没晕过去，图标一个没变，主体界面是变了，怎么变得更别扭了。又跑到开发那边，问图标怎么回事，答曰没时间改，下个版本再改。BUG呢，修改了没，答曰也没。

头晕了一阵，打开邮箱，给程序经理发了封邮件，告之具体情况，请他配合解决。天知道，这封邮件有没有用。不过，该做的还是要做的。

产品没有更新，看项目版本吧，打开了其中的一个项目版本A-1，看了一下开发提交的版本说明，都按项目计划中的完成的。于是对照了需求说明，进行一一的验证。心里还在想，负责这个项目的开发人员，真是利落，完全按计划完成了。结果......

又找到负责这个项目的开发人员，询问项目的修改情况。问完了，回来盯着电脑几分钟，打开WORD写了个版本提交样稿说明，发给开发人员了。

A-2之前和项目组、开发开过会，将所有的BUG分为几个周期修改，这次提交的是第一周期完成的，对照了一下，还不错，完成了80%，唯一的遗憾是没写BUG未修复原因和处理情况。

(三）又到了版本提交日，早上来了之后，跑到配置管理员处询问程序提交了没有，只有A提交了，其他没交，又跑到开发处催促版本提交。一圈下来，打开提交的版本开始研究。

界面终于改了，感觉不错，上个版本的BUG也大部分修复了，心里一高兴，又拉着其他同事一起过来看程序的新界面，指点了一番。

(四）经过了几周的试运行，版本可以按照规定的日期提交，并且提交相应的版本说明。虽然存在一些小问题，但整个流程可以按照预想的执行。

END：项目验收并试运行后，仍存在一些小BUG，按照预选设定的修复周期定期修改后提交版本。