分享我的发现、想法与心得

0%

基于Tower实现项目管理

经过混乱的项目管理一年时间,前端需求各种实时更新、实时修复,经历了好多次的迭代过后,现在已经无人知道这套软件的全貌。本来并没有意识到这个问题的,直到某天同事被运营问到底这个功能限制的图片比例是多少他找过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)并合并请求,到这步就完成合并。

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

1
2
3
4
5
6
7
8
9
10
11
12
新模块:



优化:

- xxxx
- xxxx

bug修复:


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

git流程走完,通知后端同事更新,然后再去tower把发布栏的任务全勾完成,这操作让我分泌大量催产素太爽了👏。