大型企业软件开发是什么样子的？ - Web Dev Cody

引用自大型企业软件开发是什么样子的？ - Web Dev Cody_哔哩哔哩_bilibili

一般来说 学技术的时候 我们会关注 开发语言特性 ，各种高级语法糖，底层技术

但是很少有关注到企业里面的开发流程，本着以终为始（以就业为导向）关注企业

是如何进行 需求 开发 单元测试 CI 部署环境 的流程，我们必须对企业开发的流程做一个

大体的了解。我参考上面视频 对 企业开发进行了一个解析。

关键词：构建系统 编码 集成 测试 部署应用

人员：

9-10个Developer（开发人员）

1个SM（Scrum Master）敏捷教练

1个PM(Product Master) 项目经理

1个用户体验师（User Experience, UX）

1个用户界面师（User Interface, UI）

若干Client（客户）

若干User（User）

客户Client收集 User用户的需求

UX\UI会做用户研究，直接与用户对接

Developer开发者用户和客户展示原型

用户经理直接与客户、开发者和UX\UI团队协作，确保项目顺利进行

Scrum主管会确保所有的会议都遵循Scrum指南

开发者会在 新特性开发 优化旧版功能 修复漏洞 里来回开发（上图这个循环）

我们梳理一下流程(一个循环)

需求收集	客户(Client)或产品经理(Product Owner)通过各种方法（如访谈、问卷调查等）来收集用户(User)的需求。这些需求可以是新的功能要求（新特性开发）、对现有功能的改进（优化旧版功能），或是已知问题的修复（修复漏洞）
用户研究	UX/UI设计师会对用户进行研究，这可能包括用户访谈、问卷调查、可用性测试等方法，以深入了解用户的行为、需求和偏好。
需求分析与优先级排序	用户经理或产品经理根据收集到的信息，将需求转化为明确的用户故事，并按照优先级排序放入产品待办事项列表(Product Backlog)中。
设计与原型制作	UX/UI设计师根据用户研究的结果设计界面和用户体验。开发者可能会参与到这个阶段，帮助创建原型并将其展示给用户、客户及团队成员。
规划与迭代	在Scrum框架下，团队成员（包括开发者、UX/UI设计师、用户经理）参加Sprint计划会议，讨论接下来一个迭代周期（通常是2-4周）内要完成的工作项。
开发执行	开发者开始编码实现用户故事中的功能，同时也会处理一些优化工作或修复漏洞的任务。
持续集成与测试	开发过程中，代码会被频繁地提交到共享仓库，并通过自动化测试来验证其正确性和稳定性。
评审与回顾	每个Sprint结束时，团队会召开Sprint评审会议来演示所完成的工作，并在Sprint回顾会议上讨论过程中的优点和改进点。
部署与发布	经过评审确认的功能会被部署到生产环境，并正式对外发布。
监控与反馈循环	发布后，团队会持续监测应用的表现，并从实际用户那里收集反馈，从而开始新一轮的需求收集和迭代。

 那么我们怎么将需求转化为一个可部署的包？接下来来讲解

我们会让开发者分成小组来进行开发，我们一般叫组群编程。

我们使用GITHUB版本管理系统来进行开发，我们需要去进行版本管理系统某一些关键词的解释

push 将你的本地更改推送到远程仓库 git push [remote] [branch]

Pull 从远程仓库获取最新的更改 git pull [remote] [branch]

Pull Request  在GitHub等平台上，你可以创建一个Pull Request来通知其他开发者审查你的代码更改，并请求将这些更改合并到目标分支。

可以看到每一个小组的合作是很紧密的，视频里的小哥使用的是ZOOM视频软件进行团队的协作

小组需要去构建新功能特性，编写测试用例确保正常运行，新特性做完后，小组成员进行一个pull request 

通常是别的小组的1到2个人对本小组的pull request进行代码审查,一旦审查通过，这个支线就会合并在主线MAIN分支，这就触发了CI/CD一一系列流水线。

我们需要解释一下CI/CD

持续集成（Continuous Integration, CI）： 在CI实践中，开发人员频繁地将他们的代码变更合并到一个共享的主分支中，通常是每天至少一次。 每次合并后，自动化构建工具会执行构建过程，包括编译代码、运行自动化测试等，以确保新加入的代码没有引入错误，并且与现有的代码库兼容。 CI的主要目的是尽早发现并修复问题，以便团队能够快速响应并解决问题。

持续交付（Continuous Delivery, CD）： 持续交付是CI的扩展，它要求软件在每次提交之后都处于可发布状态，即软件的任何版本都可以在任何时候被部署到生产环境。 为了实现这一点，除了自动化的构建和测试之外，还需要自动化部署流程。这意味着从构建到测试再到部署的所有步骤都应该可以自动完成，而不需要人工干预。 这样做可以让团队更加频繁地发布软件更新，同时也减少了手动部署过程中可能出现的人为错误。

CI/CD的流程下面这个表给出，是按照流程一步一步进行操作

源代码管理： 开发者提交代码更改到版本控制系统（如Git）。 提交的代码可能需要经过代码审查（Code Review），这是在CI/CD流水线正式开始之前的一个步骤。(就是上文所说的Pull Request)

触发构建 当代码审查通过后，代码会被合并到一个共享的分支（如main或master分支）。 这个合并动作会触发自动化构建服务器（如Jenkins、GitHubAction）开始构建过程。

构建工具： 构建工具（如Maven或Gradle）读取项目配置文件，下载依赖项，并编译源代码。 如果构建失败，则流水线会停止，并通知相关人员处理。

测试框架： 成功构建后，自动化测试框架（如JUnit或pytest）会运行一系列测试用例，包括单元测试、集成测试、性能测试等。 如果测试失败，流水线也会停止，并通知团队成员解决问题。

静态代码分析（可选）： 对代码进行静态分析，查找潜在的编程错误或不符合编码标准的地方。 工具例如SonarQube可以帮助识别这些问题。

部署工具： 通过自动化部署工具（如Ansible或Kubernetes），将通过测试的构建部署到测试环境。 根据团队的具体实践，可能会有多个测试环境（如集成测试、系统测试等）来进行进一步的验证。

 

在视频里是进行 是 GitHubAction进行了 构建 测试 部署

构建服务器是用于自动化构建、测试和部署软件的应用程序。常见的构建服务器工具包括Jenkins、Travis CI、CircleCI等。GitHub Actions 是一个内嵌于GitHub的CI/CD工具，可以直接在GitHub中定义和执行构建流程。

但是在企业里面通常不能将新特性分支直接合并到主分支里面，视频里提到，需要构建一个测试        环境供产品经理或者测试工程师来在测试环境下测试新特性进行评估。

可以看到上图 Develpor进行Pull Request的时候 是把新特性给放到了Dev环境下面 也就是开发环境

Pull Request（合并）的时候会进行自动触发的构建服务器（构建 测试 部署），也就是说在开发环境下面就会构建出一个环境 。

那么如何管理一个构建服务器环境呢？

在视频中 ，是使用AWS云器进行构建服务器的管理。

我们利用AWS的各种服务来支持构建服务器的功能。

AWS支持以下几种服务：

• 托管构建服务器：例如，在EC2实例上部署Jenkins服务器。
• 执行构建脚本：利用Lambda函数来执行轻量级的构建任务。
• 自动化基础设施管理：使用CloudFormation、Terraform或AWS CDK来创建和管理基础设施。

下面是流程

1. 源代码变更：开发者提交代码到GitHub。
2. 触发构建：代码提交触发GitHub Actions工作流。
3. 编译和准备依赖项：使用构建工具（如Maven或Gradle）编译代码并准备依赖项。
4. 基础设施配置：使用Terraform或其他IaC工具配置基础设施。
5. 构建和测试：使用AWS CodeBuild或其他工具构建和测试代码。
6. 部署：成功测试后，使用AWS CodeDeploy或其他方法将应用部署到生产环境。

当dev环境没有问题的时候，dev环境向test环境进行一个pull Request 然后test环境又会进行新一轮的构建服务器的环境生成。

test（预生产）环境和dev环境的区别在于 test环境包含更多的模拟数据，以便模拟真实环境

test环境可以邀请一批测试用户进行环境的体验，可以开视频会议 让他们控制电脑体验，也可以给一个账号让他们进去自由体验

通常 我们会在预生产环境下进行负载测试、快照测试和灰度测试

灰度测试	灰度测试（也称为金丝雀测试）是一种测试方法，用于在小范围内逐步推广新功能或版本，观察其表现并逐步扩大范围。
快照测试	快照测试是一种用于前端或UI测试的技术，主要用于验证组件的外观是否符合预期。它通常用于React、Vue.js等前端框架中。
负载测试	负载测试是一种测试方法，用于评估系统在高负载情况下（如大量并发请求）的表现。它的目的是确保系统能够稳定地处理预期的负载水平。

在预发布环境，产品负责人（产品经理）、用户、客户都会参与进来

如果预发布环境没有问题，则会直接Pull Request到发布环境里面。

这就是Terraform的好处，基础设置即代码工具，程序员不用去AWS仪表盘去进行调整，这样子的话每一个构建服务器出来之后，还要每一个调整。

每一个团队都有自己的客户 用户 和 产品，他们都有独特的方式部署代码。

存在的问题：

主环境的发布流程存在问题，未完成的工作可能被投入到生产环境中，可以在代码里面采取特征flag这种方式，如果flag不打开，否则代码不会在生产环境执行

用户或者客户可以在FEATURE DB里面进行特征flag的设置，以启用某个特定的功能

行业里面规定需要达到100%的在线率，也就是5个9的标准（大约一个小时的故障率 一年内）

，所以说根据需要 还得再不同的区域内进行一个部署一个备用的环境

比如说东海岸部署一个环境 西海岸部署一个环境，万一东海岸出现错误，可以切换到西海岸的节点（主动被动部署方式）

也有双活模式- 就是 东海岸用户只链接东海岸服务器，西海岸等同，他们之间的服务器或者其他的数据会进行同步操作，系统也要有韧性，也就是比如说opensearch集群挂掉了，那么可以从别的系统的opensearch获取数据和服务，但是一般来说国家禁止用户跨境流动。

那么 整个部署的系统如果出现bug？如何排查？

第一步，根据用户或者客户的反馈来定位,如果通过特征值数据库作为防御手段，可以进入数据库立马关闭这个特性

第二步，进行回滚部署，可能是只修改了某个lambda的代码，所以只需要lambda回滚

行业里面常见的做法是从MAIN 主分支单拉出来一个分支 在上面做改动

但是这种有问题 因为在MAIN分支上做了修改 但是 dev环境和预发布环境还是修改之前的代码，所以必须把修改好的代码合并到dev 和 staging里面去。