网站开发要多钱,广告设计公司实习报告,seo基础培训教程,电商公司注册经营范围引用自大型企业软件开发是什么样子的#xff1f; - Web Dev Cody_哔哩哔哩_bilibili
一般来说 学技术的时候 我们会关注 开发语言特性 #xff0c;各种高级语法糖#xff0c;底层技术
但是很少有关注到企业里面的开发流程#xff0c;本着以终为始#xff08;以就业为导向…引用自大型企业软件开发是什么样子的 - Web Dev Cody_哔哩哔哩_bilibili
一般来说 学技术的时候 我们会关注 开发语言特性 各种高级语法糖底层技术
但是很少有关注到企业里面的开发流程本着以终为始以就业为导向关注企业
是如何进行 需求 开发 单元测试 CI 部署环境 的流程我们必须对企业开发的流程做一个
大体的了解。我参考上面视频 对 企业开发进行了一个解析。
关键词构建系统 编码 集成 测试 部署应用 人员
9-10个Developer开发人员1个SMScrum Master敏捷教练1个PM(Product Master) 项目经理1个用户体验师User Experience, UX1个用户界面师User Interface, UI若干Client客户若干UserUser 客户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来创建和管理基础设施。 下面是流程
源代码变更开发者提交代码到GitHub。触发构建代码提交触发GitHub Actions工作流。编译和准备依赖项使用构建工具如Maven或Gradle编译代码并准备依赖项。基础设施配置使用Terraform或其他IaC工具配置基础设施。构建和测试使用AWS CodeBuild或其他工具构建和测试代码。部署成功测试后使用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里面去。
