文章目录
- 前言
- 一、企业级开发模型
- 1.1 系统开发环境
- 1.2 Git分支设计规范
- 二、企业级项目管理实战
- 2.1 DevOps研发平台
- 2.2 开发场景-基于git flow模型的实践
- 2.3 环境bug修复
- 总结
前言
一、企业级开发模型
我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段:
规划、编码、构建、测试、发布、部署和维护。
最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经hold不住了，就开始出现了精细化分工。
如下图所示:
但在传统的IT组织下，开发团队(Dev)和运维团队(Ops)之间诉求不同:
- 开发团队(尤其是敏捷团队)追求变化
- 运维团队追求稳定
双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来,这当然不利于IT价值的最大化。
为了弥合开发和运维之间的鸿沟，
需要在文化、工具和实践方面的系列变革——Devops正式登上舞台。
Devops (Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见DevOps的强大。
一个软件的迭代，在我们开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢，那不就是Git(分布式版本控制系统)!
所以Git对于我们开发人员来说其重要性就不言而喻了。
1.1 系统开发环境
言归正传，对于开发人员来说，在系统开发过程中最常用的几个环境必须要了解一下:
1.开发环境:开发环境是程序猿们专门用于日常开发的服务器。
为了开发调试方便，一般打开全部错误报告和测试工具，是最基础的环境。
2．测试环境:一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。
该环境是开发环境到生产环境的过渡环境。
3．预发布环境:该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。
其配置等基本和生产环境一致，目的是能让我们发正式环境时更有把握!
所以预发布环境是你的产品质量最后一道防线，因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内,为单独的一些机器。
4．生产环境:是指正式提供对外服务的线上环境，
例如我们目前在移动端或PC端能访问到的APP都是生产环境。
这几个环境也可以说是系统开发的三个重要阶段:开发->测试->上线。
一张图总结:
对于规模稍微大点的公司来说，可不止这么几个环境，比如项目正式上线前还存在仿真/灰度环境，再比如还存在多套测试环境，以满足不同版本上线前测试的需要。
一个项目的开始从设计开始，而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命Bug解决在系统上线之前。
测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产生直接的效益，但是它却是软件质量的最终保障，乃至项目能否成功的重要因素！！
1.2 Git分支设计规范
环境有了概念后，那么对于开发人员来说，一般会针对不同的环境来设计分支，
例如：
注:以上表格中的分支和环境的搭配仅是常用的一种，可视情况而定不同的策略。
master分支
- master为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，一般由合并release分支得到。
- 主分支作为稳定的唯一代码库,任何情况下不允许直接在master分支上修改代码。
- 产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签(tag)做记录，方便追溯。
- master分支不可删除。
release分支
- release为预发布分支，基于本次上线所有的feature分支合并到develop 分支之后，基于develop分支创建。可以部署到测试或预发布集群。
- 命名以release/开头，建议的命名规则:release/version_publishtime。
- release分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以release分支代码为基准进行提测。
- 如果在release分支测试出问题，需要回归验证develop分支看否存在此问题。
- release分支属于临时分支,产品上线后可选删除。
develop分支
- develop为开发分支，基于master分支创建的只读且唯一分支，始终保持最新完成以及 bug修复后的代码。可部署到开发环境对应集群。
- 可根据需求大小程度确定是由feature 分支合并，还是直接在上面开发(非常不建议)。
feature分支
- feature分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支。
- 部名以feature/开头，建议的命名规则:feature/user_createtime_feature
- 新特性或新功能开发完成后，开发人员需合到develop 分支。
- 一旦该需求发布上线，便将其删除。
- hotfix分支为线上bug修复分支或叫补丁分支，主要用于对线上的版本进行 bug修复。当线上出现紧急问题需要马上修复时，需要基于master分支创建hotfix分支。
- 命名以hotfix/开头，建议的命名规则: hotfix/user_createtime_hotfix
- 当问题修复完成后，需要合并到master 分支和develop分支并推送远程。一旦修复上线，便将其删除。
一张图总结：
其实，以上跟大家讲解的是企业级常用的一种Git分支设计规范: Git Flow模型。
但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把他吓一跳。
关键在于站在你的团队或项目的角度思考∶这种分支模型可以帮助你们解决哪些问题?它会带来哪些问题?这种模式为哪种开发提供更好的支持?你们想要鼓励这种行为吗?你选择的分支模型最终都是为了让人们更容易地进行软件协作开发。因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些所谓的“成功的分支模型”。
所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。
二、企业级项目管理实战
2.1 DevOps研发平台
准备工作：
Gitee企业版免费版
图示示例：
企业名称可随意填写一个测试名称，只要能通过即可。
注意:
多人协作开发，需要将多人账号拉入一个企业下才行。如何添加成员后面会跟大家讲解。
1.创建项目
图示说明：
2.创建仓库
图示示例：
注意： 创建的仓库可以关联到某个项目中被管理。
3.添加成员
（1）添加企业成员
申请后需要负责人审批通过；
（2）添加项目成员
（3）添加仓库开发人员
2.2 开发场景-基于git flow模型的实践
新需求的加入：
现有一个订单管理的新需求需要开发，
首先可以基于develop分支创建一个feature/hyb_order_20231012分支。
图示说明：
步骤1：
1.需求在feature/hyb_order_20231012分支开发完毕，这时研发人员可以将代码合并到develop分支，将其部署在开发环境的服务器中，方便开发人员进行测试和调试。
（a）开发者在 feature 分支下发起请求评审。
图示说明：
（b）审查员审查代码
（C）审查通过合并分支
（D）合并成功，查看结构
步骤2：
在develop下开发人员自测通过后，先确定下develop 不存在未测试完毕的需求，然后研发人员可基于develop分支创建一个release/xxx分支出来，可交由测试人员进行测试。图示说明：
步骤3：
测试人员测试release通过后(包含测试环境和预发布环境的测试)，就可将代码合并入master
步骤4：
测试人员在master (正式环境)测试通过后，便可删除feature/xxx分支。
2.3 环境bug修复
修复测试环境Bug
在develop测试出现了Bug，建议大家直接在feature分支上进行修复。修复后的提测上线流程与新需求加入的流程一致。
修改预发布环境Bug
在release测试出现了Bug，首先要回归下develop分支是否同样存在这个问题。如果存在，修复流程与修复测试环境Bug流程一致。
如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
修改正式环境Bug
在master测试出现了Bug，首先要回归下release和develop分支是否同样存在这个问题。
如果存在，修复流程与修复测试环境Bug流程一致。
如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。
紧急修复正式环境Bug
需求在测试环节未测试出Bug，上线运行一段时候后出现了Bug，需要紧急修复的。有的企业面对紧急修复时，支持不进行测试环境的验证，但还是建议验证下预发布环境。
可基于master创建hotfix/xxx分支，修复完毕后发布到master验证，验证完毕后，将master 代码合并到develop分支，同时删掉hotfix /xxx分支。
总结
