H.E.'s Blog

上一篇文章<百万级 J2EE Push Mail 项目后记> 说到了该项目的一些基本概况，这篇日志将讲述一些在开发过程中的与其他团队发生的故事。

这个 Push Mail 项目留给我最深的影响就是给我们团队来了丰厚的利润，客户他是一个美籍印度佬，就是我们常说的那种有钱人，做事爽快、干脆，也是全球移动领域具有影响的专家，因此他要求我们提供的服务必须是具有一个国际化专业水准的团队(International  Corporate)。所谓专业化的主要需要体现在 1执行规范、2执行效率、3执行细节 这3个重要的环节上。

在项目实施过程中除了搞J2EE 的开发者， TA、QA 、SA、DBA  一个也不能少。
1、TA 小组根据制定的项目执行规范监管我们每个开发成员 在每个stage和里程碑的执行力，从需求分析的文档编写规范一直到最后的项目交付，他们才算结束使命。

2、QA 测试团队在我们需求和概要设计 就开始对jboss和mysql其他几项技术学习，其中测试人员与我们一同参与需求分析，这样将来他们才知道该如何配合我们做各种测试，进行深入的测试，而不是我们在引导他们在测试，他们100%能知晓业务 并且制定出不同的测试计划。并不是依靠我们自己测试或者我们在指导他们测试，那样运动员和裁判员都是同一人，那样肯定出问题。

3、SA 的压力最大 需要对系统整体的架构进行设计这个都是分内的事情，更重要的 在真实生产的环境遇到致命性错误，可以回退或者拿出现成的备份方案，把问题在短时间内化解。

4、DBA  需要从高往低的系统架构层次进行对数据库设计与整体规划，必须根据客户需求设计出具有远景的 方案，不是一成不变，更不是所谓“一步到位”的规划设计，是根据预计的数据增长 进行实施规划的不同方案。

5、开发者们需要对每个业务模块都要详细了解。因为我们需要降低风险 开发者们如果出现有人家里有事或者生病 任何一个成员都可以替代，不会出现我今天不来上班，导致项目进度拖慢一天的现象。

在产品在设计开发到发布的过程中，我们分为四个阶段  prototype、demo、stage、producting。

prototype 是一个原型，主要完成核心的部分，完成核心的功能和业务逻辑，开发团队内部评估使用。

demo 阶段是将产品的主要部分演示给客户看，让客户确认主体的方向。

stage 根据项目计划分为多个不同的stage版本，每个stage阶段的版本都会在stage服务器上由我们 测试人员先测试5-7天，再发布到真实的生产环境中。客户对这样的流程要求的非常的严格。因此 stage 服务器的配置和数量与 producting 环境是100%相同的，没有他们的邮件确认我们是不能擅自发布到 producting 环境中的，如果 producting 环境出现问题，必须在短时间内能回归到上一个稳定版本的状态 。 后期会在 stage 和 producting 服务器上轮回 ，fix –> testing —> release。

我们当时使用SVN和Trac，值得一提的是Trac这个东西，客户有任何需求变更 通过 Trac 系统 TA，QA，DBA，SA  统统都会知道，并且知道我们会在下个版本 什么时候 会  发布在stage 服务器上，我们也能在第一时间知道他们对 当前版本的 性能情况，客户也能看见但似乎他们并不在意这个结果，因为他们需要知道我们当前的执行状态是否符合计划，其实TA的成员比他们更加关注我们的项目进度，呵呵。因此，所有人的开发进度执行情况都在trac上进行展现。客户也可以看见，也可以回复，所有信息所有人同步。

呵呵，另外那三十几台需要发布应用程序的机器，分别发布不同的应用程序或者不同的版本不可能完全依靠人工完成，我们需要一个半自动化的工具帮助我们完成，所以我们选择了hudson和自己编写的liunx脚本。这样可以提供效率，并且大大减少了发布时出错的机率。

先写这么多，有什么忘记的地方我回头补上，下一篇将开始 讲述 纯 技术方面的那点事儿了。

口水：

不想说的太多，怕泄露机要，言多必失。

以上文字 如有雷同，纯属巧合，私下讨论，倒是可以。

–end–