软件发布与版本管理的实践

不少中小软件公司常常被客户使用的软件与代码、需求之间不清不楚的暧昧关系搞得焦头烂额，客户现场运行1.2版本，当发现问题的时候却找不到对于的代码，更不知道需求是什么，1.2版本为什么升级，包括了哪些内容……有客户使用对于软件企业来说是一件极大的好事，往往一个好事后面隐藏着坏事，而坏事后面又有着机会，但是机会给有准备的人。怎么把这种问题转变为提高产品和管理水平的机会，从而获得更多的收益，是企业老板和管理者需要正确面对并解决的问题。

中小软件公司的现状经常是这样的，一两个核心开发人员在需要升级的时候，在自己电脑上的开发环境中制作一套运行版，经过测试后，由负责升级的人员进行上线操作。这里面有几个关键点需要特别关注，第一个就是本次版本应该在代码库中进行统一的标记，例如设置一个tag或者小版本；第二个是本次版本的代码须全部来自于版本控制系统（例如SVN），不能使用个人的开发环境进行操作；第三个要求略微有点高，就是对本次版本的需求变更、bug列表进行处理，该纳入需求的纳入需求说明书，该变更设计的变更设计；第四就是编写一个发布说明了，把本次版本发布内容进行逐条描述；最后一步，在经过一次或者多次测试，验证本次版本能够发布后，设定好版本号，再次在版本库中标记新版本。这样也是一个简单版的基线操作过程，将需求、设计、代码、发布的产品纳入基线管理，也是配置管理的一部分。

上述“人员”之所以是人员，因为他们并不具备工程师的素质，软件工程师之所以是工程师，意味着严谨的对待任何工作要求和细节。中小软件公司能力的提升，不在于有多少钱多少人多少项目，而在于研发团队素质的提升。