项目管理日志

经过混乱的项目管理一年时间，前端需求各种实时更新、实时修复，经历了好多次的迭代过后，现在已经无人知道这套软件的全貌。本来并没有意识到这个问题的，直到某天同事被运营问到底这个功能限制的图片比例是多少他找过tower找过CHANGEDLOG都无法马上能解答问题，这警示了前端组的各位。我们应该着手管理好自己的项目，就算产品经理不知道的，我们开发做过的都应该能在一些文档中找到答案。

流程

首先说一下前提，目前不论产品经理安排的新功能开发，还是运营的同事发现的问题都发布在各自管理的项目中（tower定义的项目），开发同事要知道需要做什么的情况下一般是在”我的任务”页面查看。可是这种点到点的做法并不是太好，像我们前端组每周需要共同分摊任务，但是并没有一个组内所有人的任务都显示的功能。当然还有其他情况就不一一细说，下面会慢慢说些例子。

说流程之前，先得说一下开发新功能与修复问题在优先级上是完全不同的，所以为了不影响开发节奏新功能开发的任务和bug还是老实分开管理会比较靠谱，毕竟看到bug还是会不太高兴的。开发新功能的任务我们会放在“前端工程坞”的项目，而各种问题的任务会放在“前端检修单”的项目中。

先说说开发新功能，其任务状态会从待处理-->开发中-->测试中-->已上线四种间顺序变化。

新功能任务一般都是在其他项目发起的，然后指向你。这时就得复制一份至前端工程坞项目，然后设置新复制的任务的后置任务为原任务，用这种方式把两任务的关系建立起来。这样工程坞的待处理清单就会记载所有新功能的开发任务了，前端组每周就看着这份清单分摊任务，把任务指派给负责人。后续的操作就是负责人自己去跟进了，这里组内规定任务在开发完成需要评论“已完成开发”、当提交至测试时需评论“已提交至测试”、当完成测试需评论“已完成测试”、当发布了就得评论“于xxx.xxx.xxx版本发布，已发布上线”。用此方式人工维护任务进度，虽然有些繁琐，但是在每周四发布版本并上线时写的文档中将起到非常大的作用，并且当坚持下来后，日后维护更新只需要看这份CHANGEDLOG文件就能清楚知道那些版本对应那些功能，非常的一目了然。

2019-11-28更新

今天正式走发布流程，在PR那块卡了很久，代码有冲突时无法合并导致PR不成功，后来解决了就不细说。

主要讲讲用git走发布流程应该如何处理，我们前端组已经引入持续部署工具，提交develop分支代码会同步至测试服，提交master会同步至主仓库让后端同事推线上。

目前流程是新功能统一新建feature分支，当需要测试时合并至develop，需要发布新功能的将合并至master。这种操作主要好处在于测试环境与生产环境隔离让新功能按需发布，比如：富文本编辑器新增样式已完成开发和测试，但是前台样式支持还没做好，这周四发版就不能上线这个功能了，这种情况是非常多的。

接下来说明这次新的发布流程具体怎样操作：

1. 把要发布的功能(feature)都合并至新的releases/[版本号]分支

2. 在release/[版本号]分支的CHANGELOG.md添加这次新版的内容及更新版本号

3. 在gogs提合并请求(PR)，入口最好是“代码分支->releases/[版本号]”旁边的创建合并请求按钮，将版本号作和新版的内容记录下来并提交

4. 然后管理员就可以审核代码（code review）并合并请求，到这步就完成合并。

更新描述现在是这样写的：

新模块：

无

优化：

- xxxx
- xxxx

bug修复：

无

后续需要优化的应该是hotfix的流程也需要走PR流程，并锁了master分支不让乱合并和提交。要求执行这种强制性的流程才能有效确保版本的管理啊。

git流程走完，通知后端同事更新，然后再去tower把发布栏的任务全勾完成，这操作有点爽👏。

2020-03-20更新

中间发生了比较多事情，没有办法全部说清楚……这里简单说两句，git工程流程又改了个遍，走MR（我司用的是gogs，那个不叫Pull Request，应该叫Merge Request）一段时间后又停了，因为遇到冲突的情况不知道如何处理，现在经过一番研究学习之后找到解决办法，当时没太弄得清楚概念。MR冲突时只需要在提MR的那个仓库的分支下同步一次要合并的分支就能解决，当然当时用的时候并没有想到这种处理方式。

经过一段时间实践下来，有几样东西是肯定需要的：

• 每次发布版本都要更新记录，现在点击管理后台版本号就能看到更新的记录
• 根据新功能需要创建对应的分支，比如新功能建feature分支、修复建fix分支
• 因为测试服是提供给产品或是测试的同事验收功能或是确认修复的bug的情况，完成开发的功能一般都会同步至测试服。
• 新功能通过测试后，由于某些原因导致暂时先不发布的情况（比如需要等APP端的一起上线）

现在用git-flow工作流感觉太多分支，上面也提过git-flow分支太多导致历史很乱定位问题比较难追踪到历史。通过阅读一些工作流相关的文章，了解到gitlab-flow可能是目前解决难追踪问题的解决办法。

可以阅读这篇文章简单了解一下（传送门），或是直接阅读gitlab官方文档也行。

gitlab-flow使用非常简单，master作为主要分支同时也是开发分支的任务，当需要开发新的功能或是修复问题时，在新节点下创建新的分支进行开发。当完成开发后，在CI系统中提MR给管理员，通过管理员的代码审查后便会合并到master分支上，到这步就可以部署至测试服给产品或测试的同事进行验收工作，通过验收后就可以发布了。

gitlab-flow工作流程符合敏捷开发概念增量开发功能，到这步再回看上面需要解决的情况进行思考，怎样才能满足这些情况呢？这就来一个个分析。

版本更新记录无论用那种方式的工作流应该都不影响，因为目前并没有引入自动化的记录方案，可以等工作流稳定下来再去考虑引入自动化工具帮助处理人手记录的这种情况。功能分支没有歧义，git-flow流程需要hotfix修复加急功能，而gitlab-flow并没有加急概念，所以用fix命名修复分支就行。

新功能更新至测试服这个需求要怎样实现呢？

• 猜想1：切出一个叫test的分支，当需要测试的时候合并到test分支，推送到远端后触发持续部署更新测试服代码
• 猜想2：按gitlab-flow流程，所有功能都需要提MR合并请求。当有新的MR请求时触发CI工具先在本地合并一次MR的代码然后构建部署到测试服。更好的处理办法是用类似热更新的方式实现，最好的效果是提MR后CI构建代码后推送构建代码到更新服务实现增量功能的更新，并且线上服务还可提供不同版本的选择实现多版本同时再线测试的情况。

在写上面猜想的时候发现还能结合两种情况简单实现功能，可以提出MR合并请求后CI工具自动合并到测试服，然后构建并更新。好像这种处理能比较快实现测试服的需求，接下来安排上看看效果👏。

新功能不需要发布的情况就容易解决了，不发布的MR不通过就好了，放着等要发布时再通过。

最后总结一下，基于一个master主分支来满足开发与发布的管理好像没有什么问题，打算先用移动网站的仓库试验一下看看效果如何。测试服的问题，就按上面写的MR的时候触发CI来合并到另一个测试仓库，构建完再部署测试服就能解决问题了。

纠结我两个月的问题解决🎉，试验过后再写一篇总结性的文章分享吧！😆

2020-03-20第二次更新

群友一盘冷水下来，浇灭了我的心情…

群友提出假如两个MR存在冲突的时候，合并到测试服的操作就无法通过自动化来处理。这种情况只能人工介入，但是这种情况下CI的作用就不大了。最后可能只能选猜想1的方向来实现，猜想2后最完善的情况也是会存在冲突的情况而且无法解决。