Pm角色及前端升级包相关

16,388 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
16,388
On SlideShare
0
From Embeds
0
Number of Embeds
16,070
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 7月份接手,杨洋之前负责(不堪折磨,后来他就走了),他走的时候他拉着我的手,语重心长的对我说:你要好好干,当时我没明白这是什么意思。现在四个月过去了,我明白了,但是已经来不及后悔了。\n...四个月过去了,犯了不少错,掉了不少次坑。把这里把那些掉坑与犯错中总结出来的经验跟大家分享一下,老同学们大概都熟悉流程了,新同学们就\n
  • 大家看到这个图上是一名很帅气得意的少年哈,这里我们比喻一下PM这个角色的形象。其实在很多外面那些从事别的行业的人的眼里,搞IT都是这样的形象。\n在这个角色的定位上,我们内部一定将期称为小PM。\n在大家心中的形象,Manager的形象总是胸有成竹的样子,更何况还是Project Manager呢。\n但是要记得,其实这个角色定位的关键在于“小”这个字。于是接下来将看到真正的形象。\n
  • 大家看到这个图上是一名很帅气得意的少年哈,这里我们比喻一下PM这个角色的形象。其实在很多外面那些从事别的行业的人的眼里,搞IT都是这样的形象。\n在这个角色的定位上,我们内部一定将期称为小PM。\n在大家心中的形象,Manager的形象总是胸有成竹的样子,更何况还是Project Manager呢。\n但是要记得,其实这个角色定位的关键在于“小”这个字。于是接下来将看到真正的形象。\n
  • 解释图形。。。\n大家看到图中是一个苦逼的打字员,旁边可能是他的老板或者同事,在指导他下一个字母应该按什么之类的。所以其实跟所谓的伟岸的气质是没有一点关系的。\n\n实际上前端小PM这个角色是一个相当打杂的角色,而且做的都是些拿不台面的小需求,所以往往是力费了不少,但是真正的可能就改了几行字。但是我总觉得,在把全站都扣成CMS之前,这是一个不可避免的角色。其实这个角色也并不完全像图上的那位哥们那样苦逼,因为可以完整的接解到整个研发流程,实际上对于以后大家在其它项目中的工作展开,也是有一定的帮助的。\n在这里也欢迎大家各位有志青年们能够投身到这项具有无比献身精神的事业中来,如果有任何兴趣,欢迎向我或远尘报名。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 1. 需求的接收:\n各条业务线的PD通过cq系统提交需求到PM角色,并且在cq中排队一段时间后,在每周三(前后可以提前或顺延一天,视当时资源情况而定)由PM角色发起一个新的升级包,并且把要处理的需求关联进去\n2. 需求的会审:\n在关联需求之前,有一个需求审核的过程,这个过程是由PM角色与测试负责人共同参与的,做为PM的角色,你需要对需求的实现的可能性、以及实现方式、资源安排做出保证;而做为测试方的负责人,他则需要对测试的交付和回归测试的范围、及测试资源的安排做出保证。在这个过程中,测试同学会针对交付测试和回归测试的范围、修改点、潜在的影响提一些疑问,所以最后在找测试审核需求前做好功课,对一些不懂的点,可以找相关的前端或者开发同学做一些咨询。\n3. 切流与布署开发服务器:\n在cq中点击“申请SCM创建流”后,大约五到十分钟即会创建好开发工作流,这个时候小PM可以把流布署到相关的服务器。我们前端手里目前有一批自己的服务器,但有些改动较少的系统是没有,这个时候可以找开发方面的PM角色去借服务器,网站线这边具体是华歆。\n4. 关注开发过程:\n在开始开发前,请监督对应的开发者,完成相关的前端分析文档的编写,并且上传到CQ,测试将根据分析文档及需求文档来确定他们要跑的测试用例。在写完文档后即可开始开发。\n因为资源的紧张,小PM角色将不可避免的分担一些开发的任务。如果是你自己在开发,那自然不需要自问自答的去了解开发进度,但如果是别人在处理的需求,则在从周三到下周二交付的这段时间里,你至少需要在周五及下周一这两个时间点,跟对应的开发同学沟通一下大体的进度,尽可能的保证能按时交付测试。\n5. 创建code review:\n在项目交付的前一天里,到review平台上创建相关的review,并且将review的地址填写到cq中对应的位置。并在交付测试前关注review的效果。\n6. 收集相关的CMS内容\n在每周五下班前,将新增的CMS区域汇总并邮件给前端小组对应的CMS负责人,将内容同步至线上。对于修改过的CMS内容,也要与对应的开发同学沟通下,确保线上内容也有做修改,以免出现sit环境有修改,而生产环境却遗漏的悲剧。\n7. 上传发布评审:\n某些前端日常里,将会涉及到新增环境变量、挂载CMS等内容,或者有时候会对发布顺序有特殊要求。这个时候需要在发布评审文档里详细填写对这些内容,并在每周四合并代码前将发布评估文档上传至CQ,ASA同学将人汇总各个项目的发布评估文档,并给出对应的方案。\n8. 稳定性会审\n前端这边会由徐宁牵头,组织稳定性会审,目前是由邮件的形式,由小PM写出对应的修改点(实际上,你只需要汇总一下大家在系分文档中的内容即可),将由稳定性会审的负责人来决定其改动是否可靠,对线上内容有无不良影响。\n9. 测试会审与ASA会审\n测试会审只是为了保证测试工作的完成,而ASA会审,会在一些场合比较重要,比如有新增的环境变量,挂载sharedata目录等,这些需要在发布评估文档中注明。\n10. 合并:\n当一个项目合并完,基本上已经成功了一半了,在接下来的sit回归阶段,测试同学还会发布一些bug,解决掉即可。\n现在与以前不同的一点是,如果在sit上修复bug,在cq中走流程的时候,是有一个字段需要填入code review人的。此点是为了保证代码的review覆盖率。\n11. 预发布\n每周一跟周二,会自动预发布两次,这个时候已经是真正的生产环境,一些平时难以发现的问题将在此暴露。\n在周一的预发后发现了bug,仍然解决即可,但是此时流程要复杂很多,测试也会对你小小刁难,你需要跟测试解释所有的来龙去脉,而他不一定能听懂,你能做的是再讲一遍,直到他听懂为止。\n如果在周二的预发布后才发现了一些问题,需要做一些变更动作,则需要测试提一个“预发布阶段”bug,并且在提bug过程中需要测试主管申批的,在修改完相应的代码后,再由测试同学在cq上提起重新预发布申请,一般十到二十分钟即可重新预发完成。\n在周一预发完了,你可以友好的通知一下需求方们,要其在预发上验证一遍需求是否实现。\n如果预发布上的问题都解决了,这个时候需要在CQ里做一下“预发布确认”的动作,此动作即告知ASA同学,你对此次的修改已经满意,可以按照正常的流程发布了。\n12. 项目上线:\n等到项目上线,这时需要在生产环境再次查看一下页面是否正常显示之类的,一个升级包的全部流程即走完。\n
  • 找对正确的人\n在各个流程中,会涉及到一些小PM角色无法解决的问题,这个时候,找对正确的人很重要。\n1. 需求分析:\n这个时候,负责对应的系统的review动作的前端同学往往是对这个系统比较理解的,如果你有什么不明白,可以拉他一起商量。如果大家都不懂,那么到atit平台上查到对应系统的owner咨询一般是能解决问题的。\n2. 需要开发服务器?\n写邮件给你的产品线的测试同学,要她帮你申请,现在有一个标准的申请表,其中要填对应的升级包,借用时间,归还时间,以及你想要设置的服务器密码,在收到邮件后,测试的对应负责人会将服务器资源转交给你,并在指点时间后回收。\n3. 合并冲突什么的。\n4. 发布问题,在这里特别提到一点就是属于重要区域的CMS区域发布,重要区域的发布权限是在ASA手中,需要在发布评估文档中注明,而且有些区域可能会要求有发布顺序中,请特别在文档注明,并旺旺通知ASA同学。\n5. CQ有bug不能操作下去了,这个时候联系SQA的人,他们有cq里的最大权限,可以帮你绕过某些流程,直接达到你的目的。\n\n一些注意的点:\n1. 及时的完成文档工作\n我们需要关注的文档有:1.对应的开发产出的系分文档,在此文档中主要描述对应的实现方案,修改点,新增的配置文件,新增的JS、CSS文件,修改新增的CMS文件等。\n2. 不要错过合并时间点\n因为一旦错过合并时间点,那么是需要写邮件给老大们申请延期合并的,流程非常麻烦。\n造成合并延期的一般都是审核没有通过,在项目达到merge状态之前,我们是需要搞定:1. 测试会审,此点需要测试在sit阶段关闭了所有bug,并且完成所有的回归用例后执行。 2. ASA会审,此点之前必须完成发布评审文档,如果ASA对你的文档有疑问,他会打电话给你咨询相关的问题。 3. 稳定性会审,这一点现在是由徐宁在处理,每周二的时候写邮件给他,或者参加由他发起的稳定性会审会议,告知修改点,即可能的风险。\n3. 如果要延期怎么办\n有时候因为业务方的变动,或者资源不足等原因,需要做延期的处理。在这里分两种情况,一种是单个需求延期,二是整个项目延期,如果是单个需求延期,可以在项目达到合并状态之前,你新建另外一个项目,并且联系ASA,将对应需求中变动到的代码流,重新关联到别的项目中,这样在合并时你修改的流即不会合并上去(有时候在一个流里会有几个需求同时修改,这个时候则是需要人肉处理的),另外一种情况是整个项目的延期,这种在达到合并状态之前,把项目从关联的发布窗口里取消即可,并告知ASA。\n
  • 1. review无法在项目过程中得到硬性保证\n2. 需求繁多但是都是小需求,导致修改的代码行数并不多,但是往往却耗费大量时间。\n
  • \n
  • Pm角色及前端升级包相关

    1. 1. PM & 级 —— 鹭飞 ——
    2. 2. 伟 质…
    3. 3. PM
    4. 4. And more...
    5. 5. Houston, we’ve got a problem!
    6. 6. thanks Q&A

    ×