如何高效的进行项目发版？

    对于软件项目来说，发版是软件项目必进的一个环节，同时是最后交给用户的最后一个环节，这个环节至关重要，他的好与坏直接影响着用户对我们这个软件的开发，所以再我们平时发版的时候，如果出现问题必须要用户使用前解决，同时，由于一些软件已经在用，所以，为了不影响用户的使用，我们必须要在用户没有在用的时候去升级，一般都是在晚上6点到第二天早上8点30分，这个过程包括，软件的升级，系统的测试，系统修改更新，直到现场测试人员没有发现问题后，这个才算成功的一半。什么这才算一半啊，不是已经发上去同时我们已经验证过了，这样你就错啦，我们的用户上帝还没有用过呢，要等到他们用过并且觉得没有问题，这个升版才算完成。

    所以，由于测试过程中，不能全方位的测试，要等用户使用过程中，看有没有发现一些其他的问题，需要现场人员立马地解决，可以马上处理的的，马上解决，如果在这个功能的基础上，衍生出其他比较困难的问题，这个要快速评估时间后，如果在短时间处理不了，那就要求放在下个版本处理。当然，不会出现升版主要功能用不了的问题，如果出现的话，那就不是说开发的问题，是在需求那边处理的问题，要求重新去评估需求。按照规律，往往是在系给用户使用一天后，这个版本才算升级成功。

    那么对于项目来说，发版需要什么步骤呢？这里我总结了一下，其实可以按照顺序我们来列一下：

1、首先对于发版的第一步，我们需要在测试环境中测试通过，没有发现问题，这才算至关重要的一步；

2、接下来就是准备发版的内容：版本说明、数据的割接、脚本的准备、系统配置的准备（主要是角色配置等）、安装包的准备；

3、发版完成后，测试人员按照版本说明（需求文档）测试，发现问题及时反馈给开发人员，并修改测试完成后重新发版；

4、测试完成后，测试数据的清理，以及开发人员的代码版本的备份；

5、用户使用第一天反馈与部分的Bug修改、最后才完成。

    总的来说发版的内容感觉不是那么多，严格按照顺序来，应该是可以应付的。但是，我们升级过程中，常常需要加班到晚上3，4点钟，而且还是不够时间呢？就最近三次发版来说，对于数据的割接，系统的发版我觉得浪费时间挺多的，在6点钟去发，9点钟都还没有搞的完数据的割接。

   对于我们**系统来说，发版需要发7个区，不知道有多少个域，所以发版的地方比较多。由于需要测试与修复，所以我们需要一个一个区发，而发版人员只有一个，要等把一个区都发完后，测试人员才能介入。对于我们来说，测试发现问题后，我们马上去调整，后面在去发版。这里的人员配置是这样的：1个发版人员，1个脚本升级人员，几个测试人员，包括PC端与App端测试人员，还有若干开发人员。

    在以往的发版过程中，如果要发7个区的话， 发版人员的工作量是比较大，往往会遇到脚本copy不过去，而导致发版不成功。简单的顺序是脚本的拷贝过去，到后面升级包放过去，在到测试修复。其实这些都不是太大的工作量，往往是在版本发过去后，验证后的修复，会遇到不同的问题，从而导致要把这些问题解决完后才能完成。其实，我总结出来，我们要令发版更加快，不能让参与发版的人员有等的时候，比如：发版人员在发版，开发人员就可能会空着，测试人员也是空着，那样的话，这样的时间安排就有问题啦。所以不能这样去弄，要充分利用开发人员的时间，不能让他们空着。发版与脚本的升级开发人员也可以参与，不能单单要发版人员去弄。所以我觉得可以在技术比较娴熟的开发人员那里，也安排一下脚本升级与版本升级，那样的话，发版人员就有4到5个，第一波就发版比较快。那从发版到完成还有一段时间，测试人员要做什么呢？难道他们也等着？他们也可以准备发版说明，发版的内容，以及菜单与角色的配置之类，都是为了这次发版做一个准备。这样的话，人员的安排就会最大化的运用了。

    所以，在团队中，我们要培养开发人员发版作准备，要他们懂linux 的命令，如何升级脚本，如何写sql。这一点，对于移动开发人员来说，估计比较麻烦，他们既要前端的开发，也要熟悉后台发版，确实不容易，但是要要去弄。

    另外一个主要的，也是重要的问题。如果在生产环境中发现功能的问题，而在测试环境没有发现，这个也要开发人员去解决，其实这个是可以避免的。要求测试人员在测试环境中精细的测试以及认真的测试。其实，在最近几次发版过程中也会有遇到过这个问题。那如何才能确保测试的精细与认真呢？那就应该是一个大的问题，如何才能全面的测试？我觉得主要是理解用户的需求，按需求去测试。

所以，总地来有三点：

一、前期的测试需要精细与认真，如果发现在生产上发现功能上的问题，要对测试人员进行处罚。

二、充分调动开发人员，让开发人员都参与发版与脚本升级。

三、合理安排升版时间，让升级的人员，在不同的阶段都有对应工作。