文章目录

前言
- 拓展
一、系统开发环境
二、Git分支设计规范
- master分支
- release分支
- develop分支
- feature分支
- hotfix分支
三、企业级项目管理实战
- 准备工作
- 创建项目
- 创建仓库
- 添加成员
- - 1. 添加企业成员
  - 2.添加项目成员
  - 3. 添加仓库开发⼈员
- 开发场景-基于git flow模型的实践
- - 新需求加入
  - 修复测试环境Bug
  - 修复预发布环境Bug
  - 修复正式环境Bug
  - 紧急修复正式环境Bug
总结

前言

拓展

我们知道,一个软件从零开始到最终交付,大概包括一下几个阶段 : 规划、编码、构建、测试、发布、部署和维护.

最初程序比较简单,工作量也不大.程序猿一个人可以完成所有阶段的工作.但随着软件产业的日益发展壮大,软件的规模也在逐渐变得庞大.软件的复杂度不断攀升,一个人已经hold不住了,就开始出现了精细化分工.如下图所示 :
在这里插入图片描述
但在传统的IT组织下,开发团队(Dev)和运维团队(Ops)之间的诉求不同 :

开发团队(尤其是敏捷团队)追求变化
运维团队稳定

双方往往存在利益的冲突.比如,精益和敏捷的团队把持续交付作为目标,而运维团队则为了线上的稳定而强调变更控制.部门墙由此建立起来,这当然不利于IT价值的最大化.

为了弥补开发和运维之间的鸿沟,需要在文化、工具和实践方面的系列改革—DevOps正式登上舞台.

DevOps(Development和Operations的组合词)是一种重视"软件开发人员(Dev)"和"IT运维技术人员(Ops)"之间沟通合作的文化、运动或惯例.通过自动化"软件交付"和"架构变更"的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠.在DevOps的软件开发过程包含计划讲了这么多,这个故事到底和Git有什么关系呢?

举一个很简单的例子就能说明这个问题.一个软件的迭代,在我们开发人员看来,说白了就是对代码进行迭代,那么就需要对代码进行管理.如何管理我们的代码呢,那不就是Git(分布式版本控制系统)!!! 所以Git对于我们开发人员来说其重要性就不言而喻了!!!

正文开始!!!

一、系统开发环境

言归正传,对于开发人员来说,在系统开发过程中最常用的几个环境必须要了解一下 :

开发环境 : 开发环境是程序猿们专门用于日常开发的服务器.为了开发调试方便,一般打开全部错误报告和测试工具,是最基础的环境.
测试环境 : 一个程序在测试环境工作不正常,那么肯定是不能把它发布到生产机上.该环境是开发环境到生产环境的过渡环境.
预发布环境 : 该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境.其配置等基本和生产环境一致,目的是能让我们发布正式环境时更有把握!所以预发布环境是你的产品质量的最后一道防线,因为下一步你的项目就要上线了.要注意预发布环境服务器不在线上集成服务器范围之内,为单独的一些机器.
生产环境 : 是指正式提供对外服务的线上环境,例如我们目前在移动端或PC端能访问到的APP都是生产环境.

对于规模稍微大点的公司来说,可不止这几个环境,比如项目正式上线前还存在仿真/灰度环境,再比如还存在多套测试环境,以满足不同版本上线前测试的需要.

一个项目的开始从设计开始,而一个项目的成功则从测试开始.一套良好的测试体系可以将系统中绝大部分的致命Bug在系统上线之前解决.测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一,测试往往被忽略,因为他对可以的隐性、对软件开发企业不产生直接的效益,但是它确是软件质量的最终保障,乃至项目能否成功的重要因素!

二、Git分支设计规范

分支	名称	适用环境
master	主分支	生产环境
release	预发布版本	预发布/测试环境
develop	开发分支	开发环境
feature	需求开发分支	本地
hotfix	紧急修复分支	本地

注 : 以上表格中的分支和环境的搭配仅是常用的一种,可视情况而定不同的策略.

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分支

hotfix分支为线上Bug修复分支或补丁分支,主要用于对线上的版本进行Bug修复.当线上出现紧急问题需要马上修复时,需要基于master分支创建hotfix分支.
命名以hotfix/开头,建议的命名规则 : hotfix/user_createtime_hotfix.
当问题修复完成后,需要合并到master分支和develop分支并推送远程.一旦修复上线,便将其删除.

⼀张图总结：
在这里插入图片描述
其实,以上是企业级常用的一种Git分支设计规范 : Git Flow 模型.但要说的是,该模型并不是适用于所有的团队、所有的环境和所有的文化.如果你才用了持续交付,你会想要一些能够尽可能简化交付过程的东西.有些人喜欢基于主干的开发模式,喜欢使用特性标志.然而,从测试的角度来看,这些反而会把他吓一跳.

关键在于站在你团队或项目的角度思考 : 这种分支模型可以帮助你们解决那些问题?这种模式为哪种开发提供更好的支持?你们想要鼓励这种行为吗?你选择的分支模型最终都是为了让人们更容易地进行软件协作开发.因此,分支模型需要考虑到使用者的需求,而不是盲目听信某些所谓的"成功的分支模型".

所以对于不同公司,规范是会有些许差异,但万变不离其宗,是为了效率和稳定.

三、企业级项目管理实战

准备工作

DevOps研发平台

Gitee企业版免费

在这里插入图片描述

企业名称可随意填写⼀个测试名称，只要能通过即可。注意，多⼈协作开发，需要将多⼈账号拉入一个企业下才行。

创建项目

在这里插入图片描述

创建仓库

在这里插入图片描述

注：创建的仓库可以关联到某个项⽬中被管理

添加成员

1. 添加企业成员

在这里插入图片描述

申请后需要负责人审批通过.

2.添加项目成员

在这里插入图片描述

3. 添加仓库开发⼈员

在这里插入图片描述

开发场景-基于git flow模型的实践

新需求加入

现有一个订单管理的新需求需要开发,首先可以基于develop分支创建一个feature/rose_20230710_pay分支.

在这里插入图片描述

需求在feature/rose_20230710_pay分支开发完毕,这是研究人员可以将代码合并到develop分支,将其部署在开发环境的服务器中,方便开发人员进行测试和调试.
a. 开发者在feature分支下发起请求评审

在这里插入图片描述

b. 审查员审查代码

c. 审查通过，合并分⽀

d. 合并成功，查看结果

2. 在 develop 下开发⼈员⾃测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发⼈员可基于 develop 分⽀创建⼀个 release/xxx 分⽀出来，可交由测试⼈员进⾏测试