开发过程管理地.docxVIP

开发过程管理 第 PAGE 8页 共 NUMPAGES 9页 开发过程管理  版本变更记录 配置管理 工具介绍 CI-Hudson - 构建服务器 SVN-Server - 代码管理、版本控制 Sonar - 源代码分析报告应用 JIRA - BUG、Task、Plan等跟踪管理系统 Fisheye + Crucible - 代码深度浏览、代码评审工具 Maven - 项目build框架 Nexus - lib包仓库 Mysql Server - 为以上几种产品提供数据持久数据服务器 JIRA - BUG、Task、Plan等跟踪管理系统 Mylyn–任务上下文管理无缝集成插件 Eclipse–程序员开发工具 持续集成流程 持续集成服务器Hudson从版本管理服务器SVN中，按照指定版本号checkout代码 Hudson依赖构建框架Maven实现项目构建 构建过程中从仓库管理服务器nexus中获取依赖jar包，完成后将构建工件checkin入仓库以便团队共享 Hudson通过插件将源代码变更信息更新至项目管理系统JIRA相关联的Task或Bug Hudson通过插件调用Sonar执行源代码的测试、缺陷扫描、代码覆盖率等检查，生成报告 JIRA通过插件调用Fisheye源代码变更记录 Fisheye+Crucible 根据配置定时扫描SVN服务器的仓库目录，读取源代码的历史记录（版本、注释等） 相关工具将信息写入数据库 版本号规则 主版本.次版本.增量版本 主版本：一般来说代表了项目的重大的架构变更 次版本：一些功能的增加或变化，我们定义为固定周期一次的release增家一个次版本号 增量版本：一些小的bug fix，不会有重大的功能变化 版本库目录结构 目录 说明 trunk 主干目录，存放程序员日常工作代码，总是最新的，每次release所有的新功能都在此目录进行开发，此目录的代码长期处于不稳定状态。 tag 每次release发布都会以版本号为名打一个新的tag（创建一个新的子目录），其中‘次版本号’发生递增。最后大的版本号的tag目录总是存放着生产代码，我们会通过该版本号创建分支并进行生产Bug修复，修复升级后会递增‘增量版本号’并打tag。 branch 分支所在目录，存放较稳定版本。我们会在分支上进行一些bug修复、跨release的功能开发、未知上线时间的功能开发等。 ui 美工和ui的工作目录，其中ui/design为美工设计稿，ui/html为切割组装完成的页面，html目录下的目录组织方式与实际保持一致。 release 存放目前生产上所运行的可执行码、二进制码、war包、jar包等。 tools 存放数据库变更脚本的目录以及小工具的目录。 mns 用于存放mini site的目录。 版本管理流程 整体分为：新版本的release开发阶段和老版本维护阶段 在新版本开发中，Java/美工/UI配合完成功能的开发，并进入测试和发布阶段，参看上图1～5步骤 在旧版本的hotfix维护中，程序员完成维护性开发，参看上图A～D步骤 开发工具集成 高级Java工程师/测试人员通过JIRA分配任务 JIRA将任务信息同步到Eclipse的Mylyn插件 Java工程师使用Eclipse（Mylyn），以任务为中心进行任务开发 Java工程师通过Mylyn更新任务状态，同步至JIRA中 高级Java工程师/测试人员登入JIRA 更新任务完成情况 项目管理 项目类型 项目类型可分为以下三类： 固定周期的包含新功能开发的正常release发布 由生产bug引起或临时紧急需求等需要进行的hotfix发布 由活动策划引起的minisite发布 人员角色 项目设计人员按功能分为以下角色： 高级Java工程师：需求分析、设计方案、核心代码开发、评审 Java工程师：代码开发、单元测试 测试工程师：测试案例设计、功能测试 美工：页面设计 UI：切割图片、组装页面 配置管理员：配置管理 release流程 由需求方提出需求 高级Java工程师分析需求，完成概要设计/详细设计 美工根据需求完成设计稿，UI根据设计稿切好图片并组装页面 测试根据需求完成测试案例设计 需求方、开发人员、美工、测试人员一起进行技术方案评审、页面设计评审、测试案例评审 Java工程师根据评审好的技术方案进行代码开发 高级Java工程师和Java工程师进行代码评审 评审通过后通知配置管理人员发布到trunk测试服务器 测试人员执行测试案例，如果未通过，通过JIRA定义BUG，打回工程师进行修复 测试通过后通知需求方进行验收测试 验收测试通过则通知配置管理员发布生产环境 紧急流程 接到bug反馈后，由测试人员确认bug是否存在，是否可重现等 Bug经过确认后，由高