Gitlab的项目管理
开发、测试和运维三个部门的关系
- 开发、测试、运维不是三个独立的部门，既紧密联系又相互制约
- 开发只负责写程序，将运行无误的程序提交至版本库中
- 开发不能私自将程序交给运维部署，也不能将编译好的程序给测试人员
- 测试部只能从版本库提取代码，然后编译、打包、运行、测试
- 不允许测试部门将代码交给运维部部署
- 避免代码没有经过版本库流入生产环境，造成线下与线上代码不一致
- 运维部负责部署应用程序，配置管理，只接受测试部确认无误的版本，部署代码只能从版本库中获取
项目计划 RoadMap ——– | Timeline——-O———O———-O——-O——-> | —————–
项目里程碑 项目开发计划如同列车时刻表，每个站点对应一个项目节点即里程碑。 火车偶尔也会出现晚点、取消班次、临时停车或不停靠直接开往下一站的情况，项目也是如此： 晚点就是项目延期，取消班次就是停止本次里程碑的上线计划，临时停靠即热修复和紧急上线，不停靠就是跳过本次里程碑，下一个里程碑一次性解决。 项目计划应该是像列车时刻表一样，一旦你定好，就不能随意修改，必须按照设定的里程碑有条不紊的推进。
定义工作流 Gitlab中没有工作流，我们通过标记可以定义工作流。如定义标签：
- 开发中、已完成、测试中、已测试
- 任务–>开发中–>已完成
- 测试–>测试中–>已测试
工作流设计原则
- 遵循减法原则而不是加法原则，参与人越少越好，节点越少越好
- 尽量线性，从一端流向另一端，中间尽量不要出现分叉
- 尽可能不出现逻辑判断分叉，如A审批决定下一步是流向B还是C
- 避免循环，依赖关系避免循环，即流程后退 目的是让工作流可操作、易操作、能冗余。
用好标记：
- 群组标记：公共标记定义在群组中，如 任务、测试、BUG、升级、合并、重复
- 项目标记：修改标记定义在项目中，如
- cn.netkiller/doc.netkiller.cn标记：需求文档、设计文档、产品说明书
- www.netkiller.cn标记：CSS、H5、JS
- api.netkiller.cn标记：数据库、短信、缓存、接口
- 群组+项目组合使用：升级+数据库 BUG+JS
如何写议题
- 精确描述任务
- 不使用模糊词汇，避免造成误解
- 5W2H任务分配法则
5W2H任务分配法则
- What:做什么事？
- Why:为什么做这件事？有什么意义？目的是什么？有必要吗？
- When:什么时候做，完成的时候是否适当？
- Where:在什么地方做，在什么范围内完成？
- Who:由谁负责做？由谁负责执行？谁更合适？熟练程序低的人能做吗？
- How:怎样做
- How much:成本（沉默成本）
举例：开发任务
- what：增加图片验证码
- why：用户注册登录及发帖无验证码，造成批量机器人帐户注册及发广告帖，给管理和运营造成大量困扰和麻烦
- when：2023-10-15 ~ 2023-10-25 上线
- where：用户注册处、登录与发帖处 均增加此功能。
- who：张三负责验证码生成类的开发，李四负责用户注册、登录UI修改、王五负责发帖UI的修改
- how：如何操作，开发排期及资源利用
- how much：开发人员成本 和测试人员成本
Release Notes：
项目升级时，需要写一个文档记录本次变动，内容包括：
- 新增了什么
- 更改了什么
- 修复了什么
- 未解决得问题
- 改善了什么
- 忽略了什么
changelog是更详细的内容说明。
Gitlab多任务并行开发
- 任务分解
- 配套环境 3.分支合并
任务分解
- 尽可能解耦
- 尽量避免交叉
- 理清依赖关系
-
避免循环依赖
架构师根据产品经理的产品设计进行结构分析和分解。
架构师的段位与格局：
- 企业架构师：战略规划
- 业务型架构师：业务导向技术，全局规划和实施
- 功能型架构师：根据需求文档，完成环境搭建，偶尔涉及到一些算法开发，总体来说目前国内很多功能型架构师仅仅是熟手程序员，完成搭建积木的工作。
如何拆分问题和解决问题以及宏观大局上看问题。
什么是配套环境 配套环境是指开发和测试环境，参考生产环境，以最小化实例，最小化节点，满足运行项目的环境，尽量减少环境差异，包括硬盘配置差异，网络差异，资源配置差异以及应用软件安装配置等差异。
准备配套环境
- 开发环境(development),也叫集成开发环境，为开发团队提供共享资源，因为每个程序员在自己电脑上运行一整套的分布式系统不现实，需要将公共部分抽离再来，集中提供服务，如数据库、缓存、搜索引擎、配置中心、注册中心等
- 测试环境(testing)，开发环境需要频繁合并新功能，部署、重启都会影响正常的测试，如测试一般，开发环境上加入了新功能，此时会影响测试。我们需要一台独立稳定的测试环境，该环境由测试人员控制，什么时间部署和测试自己说了算。
- 用户交付测试环境(staging)，Stage/UAT环境，Beta/Preview演示环境，定期同步生产环境数据库。
- 功能测试环境(feature/hotfix)，新功能，bug修复等。
上面三个环境，至少一台独立的服务器，功能测试环境(feature/hotfix)需要若干台服务器。功能测试环境的服务器是共享的，谁测试谁使用，用过之后释放出来。每个环境都有一整套配置的服务，例如数据库、缓存、搜索引擎、消息队列等。
代码分支 时间线分支
- 开发分支 development 面向开发人员
- 测试分支 testing 面向测试人员，
- 交付验收分支 staging 交付验收分支，俗称UAT 面向测试和客户
- 生产分支 production,面向用户 小公司中通常省去UAT环节，直接从Testing上到生产环境。 分支保护 分支保护目的是防止误删除，禁止向该分支提交代码，代码只能通过合并方式进行该分支。 分支的权限管理：
- master/main:保护，不能修改代码，只能合并，只有管理员有权限push
- staging:保护，不能修改代码，只能合并，只有管理员有权限push
- testing:保护，不能修改代码，测试人员可以合并 merge
- development:保护，开发人员可以修改代码，合并，push
- tag标签: 保护，对应Release版本。
功能分支feature 任务分解以后，每个功能对应一个分支，功能分支的代码来自development分支，我们会创建很多功能分支，开发任务在功能分支上完成开发，开发完成后将任务标记为“测试”，测试部会安排测试环境，部署该分支上的代码，测试结果分为Bug和Pending（测试通过，挂起，等待发车） 买票上车：在功能分支上，我们有很多开发完成的功能，他们处于挂起状态，然后根据升级计划，有序的合并到开发分支，再到测试分支，最后升级到生产环境。
Feature分支操作步骤
- 创建issue议题
- 从Development分支创建feature分支
- 获取Feature分支代码
- 修改代码，提交代码，测试代码
- 合并Feature分支到Development分支
- 关闭issue议题