本文为稀土技能社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！
前言
这是本系列的第五篇文章，在之前专栏中，咱们一路更新的全部都是跟技能相关的内容，那么本章咱们轻松一点，跟大家聊一聊前端运维的一些有趣的作业，也是前端走向全栈的过程中或许会遇到的一些问题。
布景
前端运维跟传统运维不太一样的地方在于，前端的更新迭代太快了，除了 SSR、CSR、SSG 之外还有各种不断推出的前端结构以及它们自己自身破坏性的版别迭代。
与后端需求长时间保持安稳的运行环境（例如有些 Java 服务或许仍是 JDK8）不同的是，前端的构建脚本需求针对各个需求以及结构做不同的更改，比方前端自动化测试的需求需求运用无头浏览器来截图，此刻就需求在对应的 Docker 镜像中装置 Chrome 以及中文字体库，这是传统后端运维没有触摸过的东西。
假如需求运维来协助处理的话，除了他自己也要不断的学习之外，也需求前端同学预研给出确定的技能计划与需求才能完结目标。并且在大前端的概念的遍及之后，APP 端以及各种跨端结构呈现，以及各个大厂推出的小程序或三方服务对接又是一个非常别致的内容。
对于运维同学来说，搭建这样的 Devops 系统要学习的内容非常多，更新的频率也非常快，并且很多内容都是碎片化的，说实话尽管做程序员便是要不断地学习新的技能，但过程真的挺痛苦的。
前端运维是我随意取的，一般都是前端架构组或许根底组做这样的作业，仅仅我管服务器的作业也挺多的，趁便就叫这个戏弄一下，不必介意也并非是新的概念。
场景复现
咱们做运维的，特别是做前端的运维保护最大的痛苦便是：每一次同学在服务器构建不成功的时分都会来找你，把日志都给你然后理直气壮的说，这个项目在我本地环境运行没问题，构建也没有问题，为什么在服务器构建不出来，你快给我处理一下，要上线了。
做了这么久的运维，前端项目在服务器构建中呈现的问题，我略微总结或许有如下这些：
- 项目依靠或许鬼魂依靠有升级，本地开发有
*.lock文件存在，所以导致即便删除了node_modules，重新装置仍是之前旧的版别，可是在服务器构建的时分一般不会上传或许读取*.lock导致装置的依靠版别不共同，呈现引证方法反常导致构建失利的情况； - 与第一个问题类似，本地全局装置了一个依靠，可是没有放在
package.json中，导致在服务器构建反常； - 本地的 Node 版别与服务器不共同，比方某些 API 只在 18 版别可用，但服务器一般只挑选安稳版别 14 或许 16，所以导致构建失利，这个时分能够挑选新的镜像版别构建或许兼容初级的 Node 版别；
- 有些项目会依靠一些特殊的服务比方 Python 等，这些三方软件在本地装置过了，可是服务器没有，所以构建也会反常，需求在构建脚本中判断是否装置此类三方软件。
希望假如碰到类似问题的前端同学，能够先按照上面的自行处理一下，减轻点运维的负担，前端发版别速度又快又频频，并且一般公司的运维资源都不会非常充分，所以必定存在照料不过来的时分，自己能挽救自己是最好的也是最方便的。假如还有漏的或许其他奇怪的问题能够谈论区留言讨论。
或许还有些其他奇奇怪怪的问题，可是大部分服务器构建项目失利的确与服务器自身关系不大，所以一般来说，只要留意防止呈现上述的问题，不会在 CI 过程中呈现反常。
由于我也归于前端出身，所以呈现这些问题我能够帮助看着处理掉，可是传统的运维他不或许懂前端开发的这些问题啊，这就或许造成了前端与运维之前的一些误会与小矛盾。
运维更重视构建过程的什么反常
呈现构建反常绝对跟服务器不要紧那是不或许的，但大部分的反常都会呈现在 CD 的过程中，所以运维更关心也能处理的是非项目自身代码编译的问题而是编译过程中的环境、服务器等问题：
- 权限相关：或许有些项目的构建脚本需求额定装置一些需求系统权限的工具，这个时分联络运维帮助给予更高权限或许构建内置后的根底镜像；
- 安全相关：运用了外部有漏洞的镜像，可是自己很难处理的话，或许某些接口（内部 RPC、外部服务回调接口等）需求开启 IP 白名单，这些能够联络运维帮助处理；
- 服务器相关：假如有项目比方 RN、APP 构建需求高性能的服务器或许 iOS 需求 Mac 来构建的话，赶忙找运维处理，硬件才是第一出产力；
- 数据库相关：对于某些服务需求数据库服务的项目，数据库的用户权限、内外网权限、数据库数据同步、备份等问题；
- 集群布置相关：比方镜像同步失利、pod 资源不足等；
在 All in Docker 的计划中，咱们能够凭借 Docker 来确保服务器也便是出产环境的统一性，确保在布置在各个出产环境（dev、test、pre、prod）中的依靠以及相关的环境变量、三方软件等外界因素共同。
可是在开发环境中咱们面临的问题会更多，比方每位同学的系统环境就或许不共同，有 Windows、Mac 以及不少神人运用的是 Linux 系统，更别说还有 Node 版别、三方依靠服务不共同以及各个开发环境所存在的各种缓存问题等等，所以很多时分遗留项目或许跨团队多人协作中处理环境依靠也是一个非常大的问题。
那么有没有好的计划将开发环境的依靠处理？
这必定也是有的，这是下一篇 Docker 系列的 【 Docker Remote Development】文章，大家能够重视下。
总结
从我的经历来看，假如公司并没有契合 Node 的业务，可是前端又想走向全栈的道路，最好的切入点便是 Devops。
上文也提到了，前端的结构种类非常多，需求针对各种不同的结构构建做兼容，即便能够统一技能栈，还会存在跨端、小程序这种需求三方对接归于前端技能领域可是又偏开发体验后端的模块。
所以假如大家对 Node 感爱好又想走全栈道路，无妨测验一下搭建一个小型的 Devops 系统先，毕竟最了解需求、有才能开发以及需求的人都是同一个人（产品+研制+用户），怎么或许会做不好呢？
写在最终
最终祝各位在全栈的路上越走越远、越走越好，继续不多的学习才是程序员的立生之本也是爱好地点。
后续大家能够继续重视【前端全栈之路】专栏，会继续更新前端视角能够触摸到的全链路非前端的常识系统。当然在全栈系统中，必定会有些技能深度不行的情况，假如有遇到解说不行清楚或许个人理解有偏差的情况，大家能够留言指正，及时修改防止误导有需求的读者。
有爱好的同学能够加我微信号：cookieboty，一起学习前端工程化的内容，互相学习，共同进步。
