feat: update my blog, two blog posts

Author: liaobinbin

content/posts/project-development-to-deployment-flow.md

@@ -0,0 +1,89 @@
+---
+title: "项目开发到部署，流程总结"
+date: 2021-12-28T09:43:43+08:00
+categories: ["Developer"]
+tags: ["project", "flow", "git"]
+---
+
+## 开发
+
+第一个阶段就是开发的阶段，首先要考虑的是做哪些功能或者调整 BUG 的顺序，根据任务的紧急程度进行划分
+
+### 需求安排
+
+#### 紧急程度
+
+应有个整体的需求清单的列表， 并且使用严格的紧急程度来区分
+
+- `T0` 非常紧急的 BUG 类问题 (严重影响用户体验和使用的)
+- `T1` 明确规划上线时间的新增需求或者功能
+- `T2` 用户提出的建议优化修改
+- `T3` 一些新的方向和领域的探索 (例如新技术，webGPU，webGL，C++构建渲染库，团队需要学习和研究的方向)
+
+#### 辅助工具
+
+如: `redmine` , `jira`, `teambition`,等等任务管理管理的工具
+
+> 就目前公司的情况而言，我觉得启用企业邮箱是一个可以实行的方向, 需要一个自动即时能通知相关人员有任务分配到自己
+> 目前我司使用的 `Jira` 可以正常发送邮件到员工的私人邮箱，最好是可以对接到钉钉或者企业微信
+
+### 代码合并
+
+为了保证代码的质量和稳定，要求合并代码的人员必须完整的`review`每一次的代码提交, 这个必然会增加代码合并人的工作量，建议从工作量上面进行调整。 对专门负责`review`的人员，减少其开发任务，来保证每次 BUG 的修改和新功能的添加都是至少经过两个开发人员的考量。
+
+### Tag 建立
+
+对于 Tag 的建立，也就是版本的建立
+除了初期的规划的版本的发布和时间节点。中途肯定也是会穿插一些紧急的 BUG 修复的发布。
+如果所有任务都如期完成，顺风顺水。那么一切按正常发布即可。
+
+#### 正常发布
+
+开发完成后，开发初步自测，自测完成创建 tag，开发给测试人员提供`changelog`, 测试人员进行集成测试和回归测试。
+
+- 测试通过，作为`release`正常上线发布
+- 测试不通过，将此 Tag 标记为测试不通过，提交`T0`的修复任务，第一时间修复相关问题。然后再次增加版本号，重新建新的 tag 进行正常发布的完整流程
+
+#### 紧急发布
+
+对于严重影响用户体验和用户使用的`BUG`, 应当出已经发布了`release`的最新版的代码拉出一个修改的分支，修改完成后，抛弃还未测试的`tag`, 将包含这次提交的代码作为新的`tag`，按顺序增加版本号。
+然后进行正常发布流程。完成后，需要将之前`release`那个版本号标记为不稳定的。
+
+> 紧急发布会打乱原本的已经在进行到一半的`tag`的测试环节。明显会增加各个部门的工作量。但是一旦正常发布能够稳定后，出现紧急发布的情况应该是非常非常少的。甚至可能没有。
+
+以上是针对可以快速被解决的紧急修复。如果是需要长时间来进行代码修复的。那么最好的方案是回退上一个稳定版本。
+将该 BUG 在后续的版本进行修复。
+
+## 测试
+
+### 单元测试
+
+对于公共库和辅助函数等方法，写好单元测试用例，保证基础函数和方法的稳定性。后期如果有相关改动的话，也更容易发现是否被引用的地方造成影响。可以让代码的后期维护可控性有较大的提升。
+
+### 集成测试
+
+### 回归测试
+
+主要测试需要进行的部分，对于测试人员已有的测试用例，针对 `changelog` 添加新的测试用例后，整体进行跑一次测试用例。
+当然如果代码模块拆分的话，可以减少测试人员的回归测试用例的数量。需要针对模块的进行单独建立测试用例。
+更推荐实现自动化测试方案，利用机器来测试对应模块，减少人员手工测试过程中产生的误操作。
+
+## 部署
+
+### 自动化
+
+自动化部署，主要是针对`jenkes`等构建工具，配合上`git hook`进行自动化发布。
+对于`master`分支应该是针对`release`后的最新代码才会合并到`master`分支。利用`release`的最新发布或者`master`分支的变化来出发正式环境的自动`trigger`构建任务并且自动发布。
+
+### 安全相关
+
+运维人员需要考虑服务器的安全问题和代码可能出现的安全问题。
+例如生产环境不应该出现`sourcemap`文件。对于服务器的防火墙的相关配置和设置应该是有规划的。
+减少使用`root`账户进行服务的启动和部署。各个服务的启动和用户权限的划分有明细的规定。
+
+## 一票否定
+
+即便是完全通过测试的版本，待发布的 tag 中。如果有任何产品或者测试，遇到任何新的异常，即便是非常小的异常。
+也许要停止该版本的发布，直到找到该问题的根本原因，或者是该问题确定被解决。或者在一定的数量级别上，该问题无法复现的情况下， 该版本可以继续发布。
+
+特殊情况 特殊处理