发表于： 2017-09-21 21:41:32
2 864
今天做的事：
第一天开始准备复盘，看了一些wiki文档，总结如下，印象笔记排版，就这样了。
首先是介绍一下复盘。
今天是准备复盘的第一天，需要读一些必要的文档，故在此整理。
先说需求
- 准备评审PPT，内容包括：
学习总结；技能总结；对开发流程的理解；职业素养；期望。
- 约相关人员开评审会。提前发通知邮件，附上ppt和任务链接。开始评审
接下来看一下做项目中涉及的一些相关内容。
一、敏捷开发
首先说什么是敏捷开发：
敏捷开发相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。 --引用自搜狗百科
简单的说就是循环开发，重复开发；区别于瀑布式开发，在开发过程中不断的自我调整。
看一下修真院的敏捷开发流程：
1.story讲解，即拆分story。软件开发术语story是解释说明的含义，这样就理解什么是拆解story了，也是需求拆分。
2.人员划分
3.方案设计，定义接口文档，前后端一起
4.方案设计，后端验证方案是否可行
5.方案评审
6.禅道拆分，单个任务不超过4小时
7.开发
8.阶段测试
9.性能测试和codereview
10.压测
11.demo；需要申请邮件，开会，发结果邮件
12.发布测试环境，集成测试
13.发布线上，停止开发环境和测试环境
14.线上监控
二、demo规范
demo前需保证项目主页各项内容已更新；保证codereview、性能测试、UI自检都已通过；demo邀请邮件提前写上demo信息，时间地点，与会人员等等。
三、打tag
tag，字面意思，即标签，我们这里指的含义是版本号；然后看一下如何打tag
1.什么时候打tag？
项目某期开发完成并测试通过需要打tag，部署到测试环境的也是tag；修改一个branch也需要打tag。
2.版本号如何定，即tag如何打？
{主版本}.{此版本}.{bug版本}
三级版本号：主版本号一般是项目期数或者重大的版本更新；次版本一般是测试打回来后重新修复的版本；bug版本一般是线上bug出现，需要添加的。
举例：修真院11期开始，版本号11.0.0；出现需求改动或者表结构变动，但扔是处于这一期的，11.1.0，每变动一次，需要叠加一次；线上bug同样是累加，如修复第一次bug，版本号11.0.1（并没有大的变化）。
3.打tag步骤
先打core包，然后Service，最后web；即先从底层开始，逐级向上，避免遗漏。
打tag前，先检查pom文件，除了module，不能有snapshot包；打tag的命令，在命令行操作，执行mvn release:prepare（以实际操作为准）；core包打完，将pom里的版本号改回到发布版本，然后执行install deploy，将其上传至maven私服，不然打web、Service的tag会出错；web和Service的core包版本号要写成release的版本号，即刚刚打完的版本（这段存疑，具体以实操为准）
打tag方式：本地打tag；通过开发工具的svn打tag；直接操作svn打tag。
4.修改bug
如果开发过程中需要修改bug，需在branches里修改。
在建项目的时候，分为三个目录：trunk、branches、tag，trunk用来放所有代码，开发也是在trunk下开发；tag是每期开发完，部署到测试环境时用的；branch是部署到测试环境后，改bug用的；打tag后，tag目录下就有相应的项目，然后在相应的branches下新建一个一样的文件夹，在本地import之前tag下的项目，然后本地更新，branch里就有相应的项目了；开始改bug时，要在branch中修改，通过测试人员校验后，打tag，发布测试环境，测试验证没有问题，bug通过后，merge（类似发布之意）到trunk中。
这里顺便提一下snapshot，快照版本。
不，是版本号规范！是maven的规范。包含SNAPSHOT、LATEST和RELEASE版本。
maven要求版本命名以
{主版本}.{次版本}.{增量版本}-{限定版本}
其中每个节点都可抛弃，但至少包含一个节点，即可以定义version为1
对于限定版本号的命名需要注意，限定版本后面是字符串排序，而不是按照数字排序，maven无法识别，可通过追加0的方式解决问题，如1.2.3-beta-3改为1.2.3-beta-003
LATEST版本，是指某个特定构件最新的发布版或者快照版，最近被部署到某个特定仓库的构件。
RELEASE版本指仓库中最后一个非快照版本。
SNAPSHOT，是maven的特殊版本号，maven在处理的时候，会将SNAPSHOT字符自动图换成时间，比如你在UTC2008年2月7号下午11:08部署，maven就会将这个版本展开成“1.0-20080207-230803-1”，换句话说，你没有发布一个软件模块，你只是发布了一个特定时间的快照版本。
关于SNAPSHOT有个很好的例子，这里简短的讲一下核心含义。
比如你在项目开发的过程中需要依赖一个相关core包，但是这个core会由于bug修复等问题在maven上多次部署，而你需要每次更新这个新的core包，这样就会有一堆RELEASE版本；maven为了解决这个问题，增加的SNAPSHOT版本，这样每次更新的都是最新版本，且服务器更新的时候会自动下载到本地，减少开发人员之间的沟通，也减少了由于版本问题出现的各种状况。
四、服务器部署
1.登陆服务器
2.在服务器上创建工程目录
3.从项目的svn中拷贝代码
4.配置Nginx
5.编辑部署脚本
6.运行脚本，部署项目
7.检验部署结果
和之前做的任务差不多
五、bug
1.bug修复流程
太多了，提炼一下
测试找到bug->开发确认并修复bug->演示是否通过，指明修改部分，部署到测试环境->测试复测，成功后关闭bug，未成功重新激活这个流程
2.bug的提交
bug要有指派人，即有人处理；标题表达清楚类型及严重程度；重现，写上步骤以及期望结果。
3.bug级别
严重度由高至低依次为：critical（危急），某一功能的bug导致的测试无法进行；block（阻塞），项目是否有闪退，崩溃的情况；major（主要），部分功能未实现，但不影响使用和系统稳定；normal（普通），界面等显示问题，基本是展示层的问题；minor（次要），可优化性能的方案等。
4.bug状态标准
待处理（new）；已确认（open）；已处理（fixed）；已修改（closed）；仍存在（reopened）；不是问题（reject）；暂不处理（hold）。
六、测试及线上环境发布流程
发布流程：测试环境每天发布，早11点与下午5点；线上环境只允许周2和周5发布；wiki上发布完成后，都要登记是否已验证；每次发布只有两种，bug修复，标明bug号，另一种是story；紧急发布登记表记录线上紧急bug修复；以月为单位更新表格；无论测试还是线上，发布时全员必须在场，方便紧急情况的沟通；开发发布测试，开发登记，测试部署到线上，测试人员登记，线上必须经过QA同意。
代码打包->登记发布日志->运维检查老版本是否备份并备份发布版本->开发验证发布是否成功，通知运维是否成功->如果发布失败，线上立即回滚至对应版本，测试环境视情况而定
七、晨会
1.时间（9:00-9:30）
2.内容
昨日完成；今日计划；演示进度；存在问题，记录不讨论，会后解决；发送晨报
3.格式
视情况而定
八、做项目需要知道的事
放在最后，再次总结项目须知
1.开发流程规范，前述
2.禅道拆解任务
3.表结构及接口注释
4.wiki登记：项目端口号；项目方案；开通项目主页；接口文档地址
5.接口文档：环境（开发、测试、线上，前端需要地址调接口）；相关功能账号（第三方账号）；后端需配置的host（Service、db等配置）；重要更新；约定（前后端约定）；具体内容（接口分配到人，接口状态，是否完成及调试完成）
6.学会使用Excel自动生成代码，然后让项目正常运行
7.测试，Service是否可以连接db；web是否连接Service
8.学会如何打日志
9.熟悉开发机目录结构，Nginx、web、Service、scallop以及停止启动脚本在哪
10.熟悉查看日志命令，如何查看日志
11.如何打tag，前述
12.发布开发环境和测试环境
13.学员复盘使用开发机2
明天计划：看一下之前老大培宇录得视频，在了解一些内容
问题:暂无
收获：一些复盘须知
返回列表
评论