【Git】--- 企业级开发流程

 Welcome to 9ilk's Code World

       

 

(๑•́ ₃ •̀๑) 个人主页:       9ilk

(๑•́ ₃ •̀๑) 文章专栏：    Git  

---

本篇博客我们讲解Git在企业开发中的整体流程，理解Git在实际企业开发中的高效设计。

---

🏠 企业级开发流程

一个软件从零开始到最终交付,大概包括以下几个阶段 : 规划、编码、构建、测试、发布、部署
和维护。最初,程序比较简单,工作量不大,程序员一个人可以完成所有阶段的工作。

但随着软件产业的日益发展壮大,软件的规模也在逐渐变得庞大。软件的复杂度不断攀升,一个人已经无法独立完成项目,于是开始出现了精细化分工。如下图所示 :

但我们知道一个公司中的开发团队(Dev)和运维团队(Ops)之间诉求不同：

• 开发团队追求变化
• 运维团队追求稳定

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

为了弥合开发和运维之间的鸿沟,需要在文化、工具和实践方面的系系列变革- DevOps 正式登上舞台。DevOps (Development和Operations的组合词)是一种重视"软件开发人员(Dev)"和"IT运维技
术人员(Ops)"之间沟通合作的文化、运动或惯例。透过自动化"软件交付"和"架构变更"的流程,
来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控,由此可见DevOps的强大。

从上面我们可以看出一个软件是需要不断迭代，不断调整更新迎合客户需求的。而对于开发人员来说，一个软件的迭代其实就是对代码进行迭代，那就需要对代码进行管理。而我们的Git这一个分布式版本控制系统正好能帮助我们进行版本跟踪管理，对开发人员的重要性不言而喻。

🏠 系统开发环境

Q：我们平时使用的APP，是开发人员开发完之后我们直接在上面使用吗？

对于用户来说 , 他们所在的环境需要是代码稳定,无bug来确保用户体验良好,开发者不能在该环境里做实验或者随意改动,否则会影响用户的正常使用。而开发者需要根据用户的需要对软件进行调整，开发人员需要一个独立环境来对软件进行自由实验，修复bug，添加新功能等。因此用户和开发人员需要进行环境隔离，等开发人员测试完才正式上线到用户线上发布环境，这也就能确保产品在上线前是稳定可靠的，同时也给予开发人员足够空间进行工作。

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

1. 开发环境 : 开发环境是程序员们专门用于日常开发的服务器。为了开发调试方便,一般打开全部错误报告和测试工具,是最基础的环境。

2. 测试环境：一个程序在测试环境工作不正常,那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。

3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致,目的是能让我们发正式环境时更有批把握!所以预发布环境是你的产品质量最后一道防线,因为下一步你的项目就要上线了。要注意预发布布环境服务器不在线上集成服务器范围之内,为单独的一些机器。

我们正式对外提供服务是在生产环境,生产环境要求代码稳定+环境配置正确,其中代码稳定测试是在开发和测试环境完成的,而预发布环境是帮助我们验证环境配置是否正确的。

4. 生产环境：是指正式提供对外服务的线上环境,例如我们目前在移动端或PC端能访问到的APP都是生产环境。

概括来说主要三个重要阶段 :  开发 -> 测试 ->上线

注意：对于规模比较大的公司来说，其实不止这几个环境，比如项目正式上线前还存在仿真/灰度环境，再比如还存在多套测试环境，以满足不同版本上线前测试的需要。

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

 

🏠 Git分支设计模型

有了环境的概念后,那么对于开发人员来说,一般会针对不同的环境来设计分支,例如:

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

Master分支

• master为主分支,该分支为只读且唯一分支。用于部署到正式发布环境,一般由合并release分支得到。
• 主分支作为稳定的唯一代码库,任何情况下不允许直接在masteer分支上修改代码。
• 产品的功能全部实现后,最终在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_hotfFix。

• 当问题修复完成后,需要合并到master分支和develop分支并推送远程。一旦修复上线,便将其删除。

以上其实就是企业级常用的一种Git分支设计规范:Git Flow模型。

注意：该模型不是适用于所有的团队，所有的环境和所有文化。如果你采用了持续交付，你会想使用一下能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模型，也有人喜欢使用特性标志。关键在于，这个分支模型能帮助你得团队或项目解决什么问题？会带来什么问题？这种模式为哪种开发提供更好的支持？你选择的分支模型最终都是为了让人们更容易的进行软件协作开发，因此分支模型需要考虑到使用者的需求，根据实际使用！对于不同公司，规范或许有些许差异，但本质都是追求效率和稳定。

 

🏠 企业级项目管理

准备工作

• DevOps研发平台 Gitee 企业版 - 企业级 DevOps 研发效能平台

注：对于多人协作开发，需要将多人账户拉入同一企业。

• 创建项目

• 新建仓库

• 添加成员

添加企业成员

添加项目成员

添加仓库开发人员

开发场景实操

增加新需求

假设现在有一个新需求需要进行开发，此时我们就可以基于develop分支新建feature分支：

由于我们在创建仓库时已经默认创建了feature分支,此时会创建失败。

此时我们只能删除仓库，重新建立仓库：

重新建立仓库时，我们需要选择生产/开发模型，此时才不会默认创建feature分支：

新建feature分支：

1) 需求在feature分支开发完毕,这时研发人员可以以将代码合并到develop分支,将其部署在开发环境的服务器中,方便开发人员进行测试和调试。

此时我们就能看到修改了

开发者在 feature 分支下发起请求评审：

审查员审查代码；审查通过，合并分支

合并成功查看结果：

2) 在 develop 下开发人员自测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发人员可基于 develop 分支创建⼀个 release/xxx 分支出来，可交由测试人员进行测试。

3）测试人员测试 release 通过后（包含测试环境和预发布环境的测试），就可将代码合并入 master 。

同样也是进行审查合并：

4) 测试人员在 master（正式环境）测试通过后，便可删除 feature/xxx 分支

修复测试环境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分支。

---