手机网站域名解析,上海网站快速排名提升,福田网站建设费用预算,松岗网站建设公司关注若川视野, 回复pdf 领取资料#xff0c;回复加群#xff0c;可加群长期交流学习一、前言 大家好#xff0c;我叫鳗鱼#xff0c;这次分享的主题是如何从 0 到 1 打造适合自己的构建部署方案。image.png先例行的自我介绍#xff0c;大概 14 年… 关注若川视野, 回复pdf 领取资料回复加群可加群长期交流学习一、前言 大家好我叫鳗鱼这次分享的主题是如何从 0 到 1 打造适合自己的构建部署方案。image.png先例行的自我介绍大概 14 年开始接触前端曾经在菜鸟实习过现在是在百度我也不知道算啥 title 的前端开发带了个小团队。前两期在女生职业发展道路上已经分享过一次然后当时说过自己对工程化这一块兴趣比较大相信懒是程序员的美德之一这次又过来做一次分享。image.png这次的话题其实说大不大说小也有很多零零散散的东西可以讲自己公司内部也有一定的实战经验甚至完善的平台。不过调研发现其实大部分中小型公司并没有专门的人去折腾这些事情也不知道怎么做或者说没精力搞那么复杂的东西。所以这次分享的话题可能比较轻松刚好大家午休时间可以边吃饭边看也不用那么烧脑。主要受众可能是一些对构建部署还停留在听说过但是没有实际用过的偏小白。时间关系也没有像其他讲师画那么多高大上的架构图。但是会比较细粒度的解析构建部署的过程希望能帮助形成一个大体的概念便于梳理能去选择合适自己的方案。具体的平台实现还可以参考其他讲师们的 PPT也都非常不错。image.png这次主体大致包含两部分第一块就是为什么我们要花那么多功夫去做构建部署的事情。第二块是我们可以怎么去做分为构建和部署两个部分。image.png二、为什么要做 项目开发流程从前端进入现代社会之后无论是看社区论坛还是各种分享都能看到各种各样讲构建部署的东西。那么它到底有什么魔力吸引大家都纷纷驻足呢我们可以从项目的整体结构来看前端其实就是软件开发交付过程中的一个小小的环节而已。通常来说一个互联网软件开发的流程如下image.png大多数都是本地编码完毕然后执行 npm run build 去做打包构建通过一定的方式推送到一个测试环境去看看有没有问题。遇到 bug 就改 bug没有 bug 就喊相关人员验收并进行部署上线。这整个流程可能有自动化的部分也有手动的部分每个团队应该多少都有点区别 通常来说自动化程度跟团队规模还有业务复杂度都有关系。但是业务如果持续发展可能一般都会经历一个过程就是刚开始我觉得这么玩玩就好了我觉得好像也没什么问题实际上会变得越来越复杂。我们理想中可能会觉得 A 项目做完了就上到 A 项目的服务上去B 做完上到 B 的服务C 做完上到 C 的服务 但是实际情况下可能会出现不同的项目模块有相互依赖的关系比如 B 服务要在 A 上线之后才能上线D 又依赖 C最可怕的还是相互依赖递归依赖传说中依赖黑洞的现象。那么这可能会出现什么问题呢image.png软件危机我们看几个历史上的实际的例子都是计算机早期的时候真实发生的故事美国银行信托软件系统开发案美国银行 1982 年进入信托商业领域并规划发展信托软件系统。项目原订预算 2 千万美元开发时程 9 个月预计于 1984 年 12 月 31 日以前完成后来至 1987 年 3 月都未能完成该系统期间已投入 6 千万美元。美国银行最终因为此系统不稳定而不得不放弃并将 340 亿美元的信托账户转移出去并失去了 6 亿美元的信托生意商机。阿丽亚娜-5 运载火箭爆炸事件96 年 6 月阿丽亚娜-5 运载火箭首次测试发射在发射后 37 秒被迫自行引爆原因由于 64 位的运算错误地变为 16 位的运算造成程序崩溃火箭感测角度失常从而触发自毁装置的启动。以上软件问题均出现在计算机诞生早期的时候计算机刚刚投入实际使用软件的规模比较小很少使用系统化的开发方法。但是由于计算机的飞速发展软件系统的规模越来越大复杂程度越来越高产生的问题也越来越突出。其实在早 1968 年的时候北大西洋公约组织在一次国际会议上就已经创造了软件危机这一词并且连续召开过几次会议提出了软件工程的概念。那么软件危机是什么呢那与我们今天要说的工程化或者构建部署有什么关系呢其实它需要解决的基本上是一类问题主要是日益庞大的软件系统其复杂度已经远超我们人脑可以直接控制的程度很难说我们靠人力靠时间就能比较好的去保证所有东西都是没问题的。image.png那么对于前端来说他面领哪些问题呢当你代码写久了可能会有一些感觉我们日常遇到的技术问题可能少一些或者说好解决一些但是工程问题反而较多而且大多缺乏系统性和通用性。比如说我们要开发一款完整的 Web 应用时我们不光要书写 HTML/CSS/JS 之类的来完成功能的开发。也将会面临更多的工程问题比如体量比较大的系统有很多功能有很多页面有各种状态要怎么去把他们组织起来再比如对于大型系统多人团队我们作为承上启下的环节怎么去比较好的进行多人甚至多团队合作开发再有就是我们经常说的性能优化问题比如说 CDN 部署、缓存控制、按需加载、首屏渲染等等。image.png所以这个时候其实我们就需要工程化了前端工程化的定义就是借助软件工程的技术、方法和思想来优化前端侧的流程、效率和规范等。参考网上将前端工程化分四个能力点规范化、模块化、组件化、自动化个人是比较认同。但是其中的每个点要细讲都能牵扯出不少的东西这次的分享只是讲其中的一部分就是如何自动化更具体来说是构建部署阶段的自动化。image.png工程化自动化说到自动化有一个可能都听说过的词CI/CD。但是他具体是指带什么我们看一下CI/CD 是指在应用开发过程中通过自动化手段来频繁向客户交付应用的方法。核心概念是持续集成、持续交付和持续部署。CIContinuous Integration简称持续集成原意是各个开发者在开发过程中需要将代码集合到一起比如我们的 GitLabGitHub 等。现在大多会包含集成之后自动触发编译测试等过程帮助开发者及时收集问题。CDContinuous Delivery指的是持续交付和持续部署经过 CI 后代码自动部署到服务器上的一个过程。image.png然后看一下市面上对于项目的开发流程过程中会涉及到的一些常见的平台这里是网上找的一张图比较糊没来得及找高清的大概看一下后面都会有详细说明代码托管我们有 GitHub/GitLab/还有国内的码云Coding 之类的平台构建对于 Java 有 Maven对于前端是 npm集成有 JenkinsTravis测试对于前端是 Mocha/Jest 之类的工具部署物理机/虚拟机/Docker K8s 等等。image.pngCI/CD 主要是自动化地在云端平台去完成这些事情。一方面来说像早上冬冬说的保持环境的一致性提高构建部署的稳定性。另外一方面就是通过自动化去减少重复机械的劳动。所以从收益来讲肯定是项目越多模块关系越复杂带来的收益越明显。image.png三、怎么做 第二个环节我们大概知道了要做什么那么具体怎么做呢构建篇image.png首先是构建刚刚说过构建指从本地开发提交到代码库以及完成远程构建自动化测试等一系列的过程。我们按顺序来看首先当你完成一个功能本地看着没问题之后去做 git commit 的时候从自动化的角度来说我们可以做什么事情image.png这里有一个很重要的点也是会贯穿构建流的一个点。就是我们要知道git 不光只是代码存储还有一系列钩子能允许你在特定的时期做一些想做的事情。例如 precommit就是代码提交前我们可以用它来做一些本地代码检查比如 ESLint再有比如自动化测试在检查通过之后再允许代码提交。通常对于前端来说我们会结合 husky 来使用。作为一个合格的校验系统当然不光只是让用户自己做本地检查就够了毕竟在某些特殊状态下大家可以有各种手段去绕过自己的检查。因此对于一些关键平台或者项目就需要服务端检查的东西了。比如目前我们自己这边的系统在代码提交之后但是还没入库之前会自动的去做一些复用率检查安全扫描等等这个就是 pre-receive 钩子可以做到的事。当然对于一些小型系统这个环节其实可以直接跳过。另外我们可能还会有 Code Review 环节代码被人审查过之后才允许合入。以及在合入之后也能有一定事件比如去通知合作方及时更新代码去通知流水线继续走后续构建的流程等等。image.png当我们提交完代码作为一个合格的 CI 系统还需要做什么事情呢就是打包构建了。这里的打包其实就是 npm run build 的过程只是执行的环境不是你本地的机器而是换成了在线的统一环境的机器比如项目测试环境的机器公司内统一的编译机等。但是他做的事还是一样的。image.png通常大多数情况来说我们执行 npm run build 然后去拿 dist 的产物就结束了。但是实际如果你玩 CI 的过程中你很有可能遇到一些环境不一致版本不一致等莫名其妙报错的问题这个时候如果你能对构建过程有一定了解在定位问题层面可能就能有一定帮助了。比如在现代化前端的演进中我们早就从解释性语言变成了半编译型语言。因此在打包核心功能时就是要把我们自己理解的代码变成浏览器可认识的代码这里举个实际的例子。image.png比如对于 TypeScript 的代码我们有 Interface有变量类型定义转化器也是会先将它解析成 AST 的语法树具体解析成啥样有个在线的网站可以查询具体的解析原理其实网上也很多资料然后根据 AST 去掉给我们看的内容变成可执行的 JS 代码。image.png当然在编译过程中肯定不止是代码转换这么简单很多时候我们有很多很多其他的配置例如 icon我们可能需要把零零散散分散在各处的图标生成 iconfont 或者雪碧图。还有代码合并压缩静态变量替换等等具体可能会做什么事情以 Webpack 为例可以参照其常见的 loader。image.png总的来说当我们执行 npm run build 的时候无论你用什么工具什么方式我们核心需要把零零散散的资源打包汇总到一起让其可执行。image.png那么常见的打包工具有哪些呢比如早一点的有 BrowserifyGulpGrunt新一点的有 WebpackRollupParcel 等等。打包这块好了那 CI 的一个核心点是自动化就是在代码提交之后能自动去运行打包的脚本而不是我在本地打包之后一起提交带代码库里面。通常来说我们可以去选择各大平台提供的现成工具例如 Travis CI这是一个跟 GitHub 强集成的 CI 平台对于一些开源项目或者自己想要练练手的时候就可以用它去玩了。左边是一份它的 CI 的配置文件大致功能就是能配置在什么阶段可以去做什么事情。另外还有 Jekins这是一个开源的基于 Java 的一种持续集成平台对于一些私有化部署的项目应该算是用得非常多的一个平台了。还有基于 GitLab 内置的平台国内的几个代码托管平台好像也有类似的服务。当然对于一些大型公司还会有自研的平台这里就不细说。image.png具体要怎么选个人觉得对于一些中小型团队建议直接找市面上成熟的工具然后结合这次大家的分享可以做一些简单的封装对于成熟度比较高业务复杂的大型团队有较强的技术中台或者有专门的人力去做这一块的事情的话可以考虑自研或者高度定制化。image.png具体怎么做无论哪种方式其实他的思路都差不多自研需要的东西也很简单首先你要有一个运行环境就是能让你执行 npm run install 和 npm run build 不会报错的地方。无论是物理机还是虚拟机还是容器都没问题。其次你需要一个代码托管平台无论是现成的还是自己私有化搭建的只要能保证以能执行 git 的各种钩子就行。然后大致的一个流程当你提交代码之后可能会去做一些本地检查这个应该是配置在项目代码库中的比如用 husky 结合 ESLint 做代码规范性检查。检查过了之后git 会自动推送代码到远程代码库这个时候可以结合服务端的 git-hook 做检查当然没有也没问题。当你收到代码提交通知的时候需要有一个 Web hook 连接通知到你配置的可用编译环境里面告诉它我有新的代码提交了你可以开始一系列后续任务。那么通常来说编译机会要做什么呢首先需要将代码 clone 下来并安装所需要的依赖对于前端来说就是 npm install 然后去打包就是 npm run build 。这样你在服务器上就已经得到了你想要的产出构建过程就已经完毕。看起来是不是觉得很简单 :)image.png但是当系统复杂度升高业务多了之后实际情况可能会遇到的一些思考点也是我们目前有的一些东西这里只是抛出来大家可以想一想。首先 Git hook 触发方式代码提交了之后是自动触发的那怎么去做到定时触发怎么去在一个代码库编译完了之后通知另外一个代码库去做编译。其次还有分支有时候我们只想 dev 分支去做自动编译master 分支需要有特殊控制怎么去更好的监听分支的变化除了精确匹配是否还可以有前缀匹配正则匹配等方式。再有就是实际业务是怎样的我需要用到哪些钩子等等...image.png然后在编译构建层面可能还会涉及到环境变量有哪些不同流程之间怎么做到一些通用变量共享。我们实际有哪些环境比如说 node8node10怎么去特定换定编译怎么切换编译所有都串型感觉太慢了我们怎么去做并行编译。机器对编译产物怎么去存储是否有定时清理机制过期时间等还有一些异常的处理超时机制各种检查具体怎么做这些都是一些细节问题也没办法在此次分享给出一个标准答案。它是一个跟业务密切相关的过程只要做了多多少少都会碰到这些问题。但相信对于一些积极思考热爱学习的同学比如能周末来听早早聊的应该能自己去探索得出答案。image.png部署篇image.png然后部署当我们拿到了产出怎么把产出给弄到不同的环境怎么优雅的上线也是一个值得思考的问题。我们再看看历史一直在说前后端分离不分离那么具体常见的前后端合作模式有哪些呢前后端完全不分离前后端在一个代码库里面前端在本地跑的时候很有可能要配置后端的服务环境提交代码后端帮忙一起部署前后端代码库分离了但是部署到机器中还是在同个服务内这个时候可能我们会把代码产出本地打包丢给后端或者说通过一系列自动化工具直接推到服务器对应的静态资源目录里面前端后端代码分离了部署也都分离开了前端这个时候通常来说可能就是一个简单的 HTTP中间可能通过一些后端路由转发的形式做关联对于一些现在的大型团队可能前端不直接跟后端对接还会有一个 BFF 中间层去做一些转发配置甚至身份校验之类的事情。image.png以上应该是一个前端开发的历史进程的缩影我们来来回回的折腾看着越来越复杂但是其实无论哪种部署都是大同小异的。image.png来看看我们的目标最前面也有说所谓的构建部署就是把各种手动操作的东西变成自动化规范化的流程。因此我们的目标就是需要把曾经手动丢服务器需要多人协同操作口口相传的这种情况。变成能由较少人可以操作由工具去帮我们自动做分发部署之类的事情从而来提高部署的效率和稳定性。image.png具体怎么丢其实很简单可以理解成是一个文件上传的过程。所以无论你使用 FTP还是有个 HTTP 请求的接口都没什么大的问题这里不做仔细描述。image.png那么我们遇到的问题可能是什么呢对于前后端分开部署前端有自己独立服务的应用可能更大的问题是应该要怎么发布毕竟服务重启这回事如果挂了分分钟影响的都是流量。这也是为什么大部分业务上线时间可能都是挑晚上上线。我们看看市面上常见的一些发布策略这个对于前端来说可能接触得并不是很多。image.png首先说蓝绿部署指我们同时运行两个版本的应用蓝绿部署的时候并不停止掉老版本而是直接部署一套新版本等新版本运行起来后再将流量切换到新版本上。这就要求在升级过程中同时运行两套程序对硬件的要求就是日常所需的二倍比如日常运行时需要 10 台服务器支撑业务那么使用蓝绿部署你就需要购置 20 台服务器显然比较耗费资源。image.png滚动升级就是在升级过程中并不一下子启动所有新版本是先启动一台新版本再停止一台老版本然后再启动一台新版本再停止一台老版本直到升级完成这样的话如果日常需要 10 台服务器那么升级过程中也就只需要 11 台就行了。image.png再有就是灰度发布这个其实就已经不算是发布策略了而是一个测试的策略。也是日常会用得比较多的一个点先启动一个新版本应用但是并不会像是滚动升级一样不断的对所有服务进行切换而是会将小部分了流量导入到新版本的环境中测试人员对新版本进行线上测试。如果没有问题那么可以将少量的用户流量导入到新版本上。这种发布方式也叫做金丝雀发布具体为什么叫金丝雀有兴趣的同学可以自己搜一搜。如果这个时候我们对新版本做运行状态观察收集各种数据并做新旧数据的对比这就是所谓的 A/B 测试。image.png说了那么多部署方式那么对我们前端来说有什么用呢一方面来说更好的了解后端的一个部署模式在跟后端或者做沟通的时候可以稍微多一些底气另外也可以借鉴借鉴知道前端要怎么玩。通常来说前端部署可能可以划分为覆盖式部署和非覆盖式部署。覆盖式部署大多就是资源在服务器上每次部署把之前的内容都删了重新替换。而非覆盖式会存储多套资源在恰当的时候去控制做资源的切换有点类似蓝绿但是没有销毁的过程。对于个人来说我们这边可能目前用的比较多的是非覆盖式将资源都部署到对象存储上面例如阿里的 OSS百度的 BOS去使用它们的 CDN 功能。然后在 Nginx 或者哪一层去控制资源的版本切换或者说默认使用其 lastest 的版本。image.png那么对于普通的业务开发我们应该怎么选呢上面说的各种部署方式市面上很多云平台都有一定的支持。因此对一些业务简单的小团队可以考虑直接找个云平台然后撸一撸公共脚本或者服务串一串就可以开心的玩耍了。对于一些业务庞大复杂有人力精力的情况下也可以考虑弄一个可视化的流水线平台像是早上其他讲师分享的。这建议是在有一定规模之后且简单模式 run 了一定时候再去搞。image.png具体可能会涉及到哪些东西呢首先呢还是一样需要有一个环境可以跟上面说的编译环境保持一致。然后拉取打包后的产物并将产物发送到指定的机器/CDN期间可能会涉及到一些服务之间的关联部署模式等。image.png这是我们这边的一个流水线平台的大概例子它大概的功能可以远远不止 Web 的构建和打包还有像是客户端Server 类型的不同环境的编译都是以插件的形式集成到其中。另外还可以做一些常见跟发布相关的功能比如打版本号提测环境切换发单审批等都可以在这里进行。image.png然后对于部署同样有一些思考点这里也是列举不做详细的解答比如怎么制定部署到不同环境怎么去做权限的控制然后部署成功的通知失败的回滚和通知怎么去打版本号还有对于前端 Sourcemap 怎么存怎么做关联日志怎么去做上报存储分析对于物理机虚拟机Docker 等不同形式我们怎么去做部署。image.png另外如果自己搞平台那么我们的关注点除了构建部署我们还能做什么别的事情比如说代码跟需求卡片关联自动提测各种服务端的检查各种测试审批等等。思路层面这里基本就讲完了。image.png四、总结 总的来说以上就是构建部署的一个简单介绍。对于具体业务不同的方向的需求多多少少都有些不同这也是软件开发中一个比较难的部分。这次分享只是做了细粒度的思路拆解具体方案其他讲师也都说得很清楚。这里引用人月神话中一句话“软件开发中最困难的部分是规格说明设计和测试这些概念上的结构而不是对概念进行表达和对表达完整程度进行验证。所以软件开发天生就没有银弹”。这里核心想说明的就是构建部署没有银弹大家需要根据自身情况做各种调整希望大家都能早日造就适合自己的方式。image.png既然说到这里了那么分享例行需要推荐的书就是这本《人月神话》。被很多人都推荐以及评分都特别高的书刚开始看可能看不懂当你有了一定经验项目达到一定规模之后再回头来看可能会有不一样的体会。推荐阅读我在阿里招前端我该怎么帮你现在还可以加模拟面试群如何拿下阿里巴巴 P6 的前端 Offer如何准备阿里P6/P7前端面试--项目经历准备篇大厂面试官常问的亮点该如何做出如何从初级到专家(P4-P7)打破成长瓶颈和有效突破若川知乎问答2年前端经验做的项目没什么技术含量怎么办若川知乎高赞有哪些必看的 JS库末尾你好我是若川江湖人称菜如若川历时一年只写了一个学习源码整体架构系列~(点击蓝字了解我)关注若川视野回复pdf 领取优质前端书籍pdf回复加群可加群长期交流学习我的博客地址https://lxchuan12.gitee.io 欢迎收藏觉得文章不错可以点个在看呀^_^另外欢迎留言交流小提醒若川视野公众号面试、源码等文章合集在菜单栏中间【源码精选】按钮欢迎点击阅读也可以星标我的公众号便于查找
