利用GitHub进行敏捷开发管理

以前使用GitHub一般就作为版本管理+bug管理，都是个人使用，这次公司全部统一使用GitHub企业版进行开发管理，在使用过程中感觉还蛮不错的。可以实现类似看板的功能，还很便于交流。

项目管理

在记录GitHub应用前，先来看看项目管理的一些情况。整个项目偏向于敏捷的管理方式，尽量简化，当然也不是完全一样。项目前后端完全独立，采用REST接口。

• 迭代：两周一迭代（又看作一个milestone或者sprint），每个迭代开一次迭代会议，迭代会议并不会冗长，一般在1小时内完成，关注点在迭代中产生的需要分享的问题以及遇到的需要讨论的问题。
• 开发环境：准备了专门的开发服务器、构建服务器，用于构建以及部署服务，还有一个独立的集成测试服务器，用于自动化定期部署服务及集成测试。开发工具使用IDEA，并且使用编码约定，包括统一的Code Style、import顺序配置、static import配置、CheckStyle插件配置、换行符设置，以保证每个开发人员格式化都是完全一致的。
• review：所有PR（PullRequest）必须至少2人（子团队4个成员）进行review，实际执行过程中，基本都是所有成员全部review后才进行merge的，只有部分大范围重命名或者很小的简单修改除外，当然，这个是约定，这个没有技术手段限制，缺点很明显，review需要占用不少时间，优点也很明显，一个是代码质量更高，另一个是都比较了解所有代码，可以互相替代。在执行过程中发现，花费一些代价review是值得的。但也不一定这么死板，总的来说，前期最好所有成员都进行review，可以起到整体风格统一的作用，而且很高效，也可以让大家都了解整个项目的大体情况。
• 持续集成（CI）：这个是使用Jenkins完成的，每日定时构建并部署到开发服务器。项目的特点是前后端分离，及时的部署到开发服务器便于前端开发测试。除了每日构建，Jenkins利用Git和GitHub插件与GitHub集成，在每一次PR有提交的情况下也会触发构建。Jenkins构建使用的是maven，除了编译、单元测试以外，还会进行Findbug、CheckStyle、单元测试覆盖（JaCoCo）等检测，保证PR中没有Findbug的最高级别警告以及没有CheckStyle的任何警告。
• Profile类别：local、test、dev、alpha、stage、real，local是指开发人员本地，test是指单元测试，dev是指开发环境。
• 接口定义：没有采用专门的文档，使用Swagger在代码中定义。先期在GitHub的wiki中专门有一篇文档，后来感觉重复维护容易遗漏，就没有使用了，都以Swagger定义为准。

GitHub常用功能

git作为项目仓库进行版本管理这个大家都只到，GitHub的Code不需要在介绍了。这里只介绍与开发管理相关的功能，而且假设大家已经了解了基本的操作。

• Issues：问题单，不要仅仅把它看作别人提单自己改进的功能，借助自定义label，它可以包罗万象，可以是功能点（new feature）、改进点（improvement）、研究技术（research）、分享信息（share）、讨论问题（discussion）等等，为什么把这么多东西都当作issue呢，因为一旦使用issue来管理，就可以利用GitHub功能很方便的跟踪、通知、引用关联等等。比如一个需要讨论的问题，可能是在完成某个功能issue的时候产生的，就可以方便的refer哪个功能issue（#issue号）。
• Pull Reqeust（PR）：合并申请，在分支上进行了一些修改，需要很并到其他分支，就需要创建一个PR，一般情况下的配置就是要求需要review后才能合并。在提交PR的时候，约定需要写明关联的issue，以及该PR涉及了哪些改动，以方便他人review。
• Wiki：可以用来存放一些简单文档，比如需求描述、开发约定、开发环境说明等等，总之，需要成员都知道而且需要随时查看的都可以放到这里。

ZenHub介绍

这是一个Chrome的插件（所以还是用Chrome好呀），ZenHub主页上可以看到，它就是用于敏捷管理。安装插件后只需要填写帐户信息即可。
插件安装后再打开GitHub页面，就会发现多了两个功能：Boards和Burndown。Boards就是便于issue状态管理的，类似看板，在不同的状态栏中的issue可以随意拖动到其他状态栏，就可以变更issue状态。具体一些操作就不详细说明了。

Burndown（燃尽Report）就是一个信息汇总。除此以外，还可以在Boards中看到有一栏叫做Epics，这个是多个issues的集合，在创建issue的时候在右侧还可以看到多了pipeline和estimate的选择，estimate就是评估的价值。

下面主要介绍一下工作流程相关的常用功能。

• Epics：在创建New Issue的时候，会多出一个Create an epic选项，可以创建epic，epic的含义就是一个稍大的工作，它包含多个子工作（issues），一开始工作的划分可能并不能很细致，因此创建epic比较合理。确定子工作后，可以把issue添加到epic中。
  
• pipeline：工作线，其实含义就是处理的状态，整个状态串起来就是工作流程，pipeline可以自定义，一般使用默认的就可以了，默认包括以下几个状态：
  
  • New Issue：新创建的issue默认就是这个状态。
  • Epics：这个不是状态，就是指epic。
  • IceBox：冻结issue，暂时不去完成，可能是issue太复杂或者需求不确定等等。
  • Backlog：issue计划执行，就是迭代会议的时候确定哪些工作需要完成，那么相应issue就变更为backlog状态。
  • In Progress：在进行中，一旦开发人员着手执行issue，就变更为in progress，当然，这里就要注意了，在进行中的issue一定要有指定的开发人员（Assignees），这样可以避免重复工作。
  • Review/QA：等待或正在进行review或者QA测试。
  • Close：关闭，确认完成后变更为关闭。
  • Done：已经完成，这个状态比较特别，前期是PR合并后变更为该状态，在迭代会的时候大致梳理，确认完成就变更为close，后来认为这样很耗时间，也没有起到什么作用，就约定，如果是开发阶段issue，完成后就变更为close状态，如果是需要QA测试的，才用到Done状态。

工作流程

以一个迭代来说明：
1. 创建一个milestone，命名需要有一个规范，便于识别。
2. 根据需求创建issue和epics，如果issue之间有关联，就引用即可。
3. 根据进度要求及当前完成情况，将当前迭代计划执行的issue的pipeline变更为backlog。
4. 根据情况自行领取或指定负责人员，开支进行时将issue的pipeline变更为in progress。
5. review变更，通过后，合并分支，删除分支。在项目中约定，由固定的两个成员来进行合并、删除分支的操作。合并的comment需要@各个review成员。
6. 不需要QA测试的issue一旦review通过，就自行将pipeline变更为close。如果需要QA测试，则等待测试，测试完成后，如果通过则变更为done，经开发确认后close，如果未通过，则变更为in progress继续进行。
7. issue的处理有不同的方式

• 设计类issue：提交设计方案（图、表格、文字等等），然后直接@各个成员，让大家来review，直接在comment中讨论，并最终得出结论，需要在issue的最后的comment中确认。
• 开发类issue：创建一个git分支，命名为#[issue号]_描述，push到远端。然后在本地分支上进行修改，重要的commit comment中引用issue号，尽量合并commit，完成并push到远端，提交PR（在此最好合并主分支）。

其他约定和建议

• 尽量多的利用GitHub，能在GitHub上进行的工作都用GitHub，这样互相关联，查找跟踪更加方便。
• 在各种comment中可以引用各种内容，比如#引用issue，@引用人员，还可以直接粘贴url，比如可以粘贴某一个comment的url（comment的时间是一个超链接，这个链接url就是comment的url）。下图中两个蓝色框，第二个就是其他issue引用了这个issue，可以很方便的链接过去。第一个蓝色框是在git提交时，在comment中引用issue，一旦引用，在issue中就可以看到相关的commit。详细参考GitHub说明https://guides.github.com/features/mastering-markdown/。
  
• wiki中如何添加附件？wiki中无法上传文件，但是issue的comment可以上传，因此，可以现在comment处上传文件，上传后可以得到文件的url，复制这个url到wiki中，就可以引用到该文件。可以注意到，其实各个元素都有固定的url（符合REST风格），都可以使用url进行引用。（但是附件支持的格式有限，有的时候只能改一个后缀名进行上传，比如sql文件，就可以改成txt文件上传）
• 强烈建议最终需要执行的issue足够小。尽量小的issue将使得工作进度更可控，任务更明确，修改也更简单，如果issue需要对应PR，PR需要review的变更会比较少，这样review的进程也会加快很多。在项目中，采用的衡量方式是issue的完成不超过3天。或者PR的变更在10个文件以内（当然不是必须的规定，而是指在一个范围内其他成员会乐意review，如果过多修改，review会变得很困难很耗时，经常会出现拖延现象），因此，这也是issue划分的一个重要依据，要尽可能的推动review，推动进度。
• 在comment中交流的建议：多利用列表、图、表格，附加文字说明，这样更容易理解，有问题时除了提出待讨论的问题，最好描述一下各种可能的方案，这样效率更高。