每周定期发布新版本的版本管理策略

今年开始在团队内使用新的版本管理策略，以便达到每周定期发布的模式。以前按功能发布，经常有大功能需要几周开发，并行的小功能需要几天，而导致小功能需要等大功能开发测试完毕才能发布，拖延了一些重要功能，不适合互联网开发模式。新的版本策略每周定期发布新版本，只发布已经测试完毕的功能，未经过测试的留待以后发布。

工具

• 使用git做版本管理 【必须】
• redmine作为开发+测试（不含测试用例管理）的日常工具 【可选】
• pmwiki管理文档 【可选】

分支策略

下图是一个简单地分支模型，当多个项目有公共的部分时，master, prerelease分支要有对应的多份。

• develop分支，开发的主干分支，所有开发以此分支为基础且只有开发完毕的功能才会提交到此分支。每天会自动从develop取出程序发布到测试服务器，形成nightly version，供提前测试发现问题。

• master 是发布到生产环境的版本。

• prerelease仅仅在测试开始时才创建，测试完成后删除。

• feature_x在开发新功能时创建，功能开发完毕后删除。

• 当有新功能需要开发时：

  1. 创建一个feature_xx分支，xx以功能的名字命名（注意不要用中文，中文会导致redmine出问题）
  2. 其他开发人员checkout此分支，大家日常提交代码到此分支
  3. 开发人员每日从feature_xx拉取其他人（共同开发此feature_xx功能的同事）提交的代码，也要从远程develop分支合并到本地（图中#1，合并后不提交到远程服务器），这是为了避免最后合并冲突麻烦。
  4. 开发完成后，合并代码到develop分支，并删除feature_xx分支

• 需要发布新版本前

  1. 确认需要发布的功能都已经提交到develop分支后，从develop分支创建prerelease分支
  2. 测试prerelease分支
  3. 如果有bug则在prerelease分支修改，改后合并到develop分支，注意千万不要在develop分支修改，改后合并到prerelease分支，这样会把其他人提交的东西也合并到prerelease分支；如果bug被允许在后续版本中修复，则bug另建feature分支修改
  4. 测试通过后，提交prerelease分支到master分支，并打TAG标记（标签采用 前缀+日期+序号 形式）。之后删除prerelease分支
     从master分支提取代码部署到生产环境

• 当生产环境发现重要bug，需要紧急修复时

  1. 如上图#3红色节点
  2. 从master分支checkout出对应的代码，修复后测试通过提交到对应的master分支，并形成下一个TAG和生产环境发型版本。
  3. 提交修复到develop分支
  4. 如果存在prerelease分支，则提交到prerelease分支。（不存在prerelease分支时，不需要此步骤）

• 测试组一般工作在prerelease分支上，开发组一般在feature（开发期间）和prerelease（测试期间）工作

• 紧急修复时测试和开发都在hotfix上工作

Commit Message

• 每次提交都必须写Commit Message，不要写无意义的信息。
• 提交内容和redmine有关联时，要关联redmine上对应的问题编号，例如：
  • 修改了101号问题，耗时3个半小时，但没有全部完成则可按照如下格式写refs #101 @3h 30m {中文注释}
  • 如果101号问题修改完毕，则用fixed关键字开头 fixed #101 @2h {中文注释}
  • 时间只写此次提交内容花费的修改时间，redmine会自动累加。
  • 中文注释写解决问题的技术实现办法，不用描述问题本身，因为问题已经在redmine上有说明。

开发测试日常工作流程

1. 周一确定一周开发内容
2. 周一~周二测试上周发布到release分支的内容，并修改bug
3. 周三发布到生产服务器
4. 开发人员在周五完成本周开发内容后提交到develop分支，周五下班前提交到release分支。
5. release log，每周从周一开始记录直至发布

注：上述流程看上去程序员会同时做很多事，开发、修改bug等等，其实大部分时间这些不是并行，因为每周要发布的内容中不是包含所有程序员的工作，可能一个程序员负责的部分2周甚至更长时间才有新功能发布一次。