代码管理 =========== 主要涉及到项目库的规划及代码管理。 角色定义 ----------- * 开发角色，开发功能并提交代码的开发工程师。 * 集成角色， 将开发角色的代码从子工作空间集成到主干的角色。集成工程师发布版本并建立基线。 规划配置库 --------------- 按功能划分 ``````````````` 配置库按功能划分为三种，交付库、代码库和文档库, 以下为大多数配置管理非专业公司的划分。 :: 1. 代码库：用于存放开发过程中源代码. 代码库用SVN系统实现。 2. 文档库：用于存放开发过程中文档，以及项目管理活动的相关文件。 目前文档库用VSS系统实现。 3. 交付库：用于存放开发最终工作成果文件。 交付库用VSS或VSFTP实现。 这种方式是不合理的划分，无法找出某个时间点的所有资料。例如假设项目进行到三期， 我想找到某个子模块1期的需求、设计及代码。这种划分很难实现类似的要求。 按受控级别划分 ---------------- 配置库按功能划分为三种，开发库、受控库(基线库)和交付库(产品库) * 开发库，开发人员进行开发过程中的代码及文档，经过评审进入受控库 存放开发过程中需要保留的各种信息，供项目组成员使用。 * 受控库(基线库)，受到控制，如果修改需要经过批准。在软件开发的某个阶段工作结束时， 例如开发代码可能会定期(每周)建立基线用于同步研发人员之间的工作。 将工作产品存入或将有关的信息存入。对库内工作产品的读写和修改应该加以控制，例如至少编译通过，实际上到了项目后期基线的创建非常频繁。 * 交付库(产品库) 基线中经过测试交付给客户的产物，在开发的软件产品完成系统测试之后， 作为最终产品存入库内，等待交付用户或现场安装。对库内工作产品也应该加以控制。 * 如果使用subversion来做配置管理系统，开发库和受控库一般采用同一个物理仓库，采用不同的目录来表示。 tags下为受控库，其他目录为开发库，一般交付库的二进制安装包采用ftp服务器来保存。 版本库布局 ----------------------------- :: /trunk 项目开发主线目录，存放开发代码 /tags/ 开发或交付过程中定期建立的基线。例如在开发过程中，每周创建基线。 /branches/ 存放分支,或建立交付产品线，在功能开发完成后，建立交付产品线进行fix bug. 例如功能开发完成之后创建1.0的分支基线修改bug并进行发布 /cws/ Child Workspace个人工作空间，个人基于迹象创建分支来提交代码，存放个人与开发有关功能分支代码。 /vendor/ 卖主分支或供方分支，用于存放并跟踪第三方代码。在你的软件会用到其他人的代码或软件库时，跟着第三方代码。 trunk,tags和branches为subversion推荐的版本目录，cws为本书推荐创建的开发人员私有目录，每一个子目录可以自由创建， vendor为保存第三方代码目录，第三方是相对于客户和项目组来说，便于项目组跟踪第三方代码，一般签订合同时有甲方，乙方之说， 甲方一般为购买方，乙方为提供商。 :: / trunk/ tags/ branches/ cws/ vendor/ 如果多个项目采用同一个版本库，可以采用同样的布局，只是版本库顶层为项目产品名称，例如 :: / ebook/ trunk/ tags/ branches/ cws/ vendor/ voip/ trunk/ tags/ branches/ cws/ vendor/ ... * 注意：不使用demo等来作为版本库顶层路径，因为一般演示版之后，会继续进行开发，这是demo的含义将不符合长远需求。 * 同样的道理，版本号，例如1.0等也不要作为代码库顶层路径。 目录权限划分 --------------- * cws 目录，私有工作空间，开发角色，可以读写。 * tags 目录， 集成角色，可以读写，开发角色为只读，不允许提交修改。 * 其他目录:均可读写。 其他目录根据项目规模大小，有不同的权限划分，对于规模较大项目，有大量的开发人员，一般超过30人， 设置有专门的集成人员，这是仅有集成人员有权限在branches，trunk和tags下进行操作，开发人员在cws目录下提交代码， 代码完成之后进行验证，通过之后由集成人员进行提交到trunk或branches中，经过阶段研发，再创建基线(tags下建立快照) 对于小项目来说，开发人员很少(10人以下)，一般没有专职的集成人员，开发人员直接在主干上提交， 兼职集成人员建立基线。 即tags下仅集成角色有读写权限。其他目录均可以读写，这样可以简化管理和流程。 始终创建分支 ----------------------------- * 项目很大，人员很多，并且模块划分不具体，修改一个功能可能设计到多个模块 * 每一个任务均创建一个分支来提交代码，验证通过后有集成人员集成到主干中 * 适用于大项目，或者项目后期，为了控制主干代码质量，需要控制代码提交。 主干提交 ----------------------------- * 研发人员较少，通常小于8人，均可以直接沟通。 * 每个人均直接向主干提交代码，因为项目较小，不设置专门的集成人员，研发人员同时担当集成角色的功能。 * 每次提交前更新代码，验证通过后提交。后提交的研发人员负责解决代码冲突。 使用主要原则 ----------------------------- 1） 使用自己的账号来下载及提交代码。 2） 提交代码必须写注释。subversion提供钩子来强制用户来写提交注释，另外制度上需要有所规定。 这个在短期可能会影响效率，但长期来看会提高效率。 3） 开发库(代码库)禁止提交可以自动生成或编译生成的文件(例如编译生成的动态链接库，安装包)，生成文件会导致代码库变大，下载时间变长， 其他研发人员可能在生成文件修改导致功能被覆盖等。 4） 对于新功能通常新建工作分支来提交代码。 5） 代码尽量每日提交到自己的工作分支上。 6） 个人工作分支中的工作尽量尽早合并到主干. 7） 个人工作分支不重用，如果某工作分支已经合并到主干，请新建工作分支完成新的工作。 8） 对于开发的功能需要在自己编译通过后才可以提交到开发库中。针对在主干提交的情况， 因为会导致其他人编译不通过，影响项目整体开发效率。 9） 对于跨平台代码使用同一个开发库，使用条件编译来实现多平台，这样可以减少工作量，并且接口对外一致。 例如android平台使用ANDROID来判断平台。 开发管理 ----------------------------- 版本管理，一般开发经验认为以一个固定频率发布会协调开发人员和测试人员的开发节奏，让开发有效率的进行。一般建议每周最少发布一个集成版本。 对于测试力量较强（每天即可对全部测试用例进行测试），可以每天项目内发布一个版本。 对于代码管理中的代码集成，一般做到每天集成，每天构建(daily build)， 集成人员进行适当的冒烟测试，在某些公司称为入门测试。 冒烟测试不通过，代码打回到代码提交人员，并说明打回原因。 对应整个大项目各个模块有依赖关系的，架构人员应当指明依赖关系，架构人员或集成负责人应当根据开发计划编写集成方案和集成计划。 代码提交，提交必须写提交日志。每个人可以有自己的独立工作空间随时提交，不受限制，但建议每天提交一次，如只有组内工作空间， 没有个人独立工作空间,只要不影响他人开发可以随时提交。工作空间(workspace)是指 svn 的一个目录。 工具 ---------- 好的工具可以提高软件开发效率，以下是我推荐的一些配置管理软件。 * subversion 或 git. * Jira 或 bugzilla. * buildbot 或 jenkins * wiki. RST(reStructuredText)或MarkDown保存文档 * 代码搜索引擎 opengrok * 邮件列表 大多数开源社区，都会建立项目邮件列表，将项目相关人员都加入到邮件列表中，邮件永久保存，解决人员流失导致知识传承的断续。 需求的讨论，以及变更管理，会议召集及会议记录，都通过邮件列表来组织。该邮件列表也可以通过web进行浏览查看。 术语总结 --------- * 冒烟测试, 该词来自硬件行业。对一个硬件设计进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。 在软件中， “冒烟测试”是指快速验证软件基本功能是否有缺陷。 * CWS, Child WorkSpace的缩写，是开发人员的私有工作空间，通常可以认为是开发人员独有的svn上的一个目录或者git上的一个代码库。