软件开发一般不会上来就是最终版本，而是会一个版本一个版本的迭代。 新版本上线前都会经过测试，但就算这样，也不能保证上线了不出问题。 所以，在公司里上线新版本代码一般都是通过灰度系统。 灰度系统可以把流

Docker 对前端的意义也很重大。 实际上，Docker 的世界里，并不区分什么前端、后端，没有人说只适合后端、不适合前端 … 在运维的眼里更是如此

本文介绍通过 Jenkins 构建流水线的方式实现全链路灰度功能。在发布过程中，为了整体稳定性，我们总是希望能够用小部分特定流量来验证下新发布应用是否正常。即使新版本有问题，也能及时发现，控制影响面

先上灵魂拷问 在文章之前，先抛一些灵魂拷问： 前端代码从 tsx/jsx 到部署上线被用户访问，中间大致会经历哪些过程？ 上述过程中分别都有哪些考虑、指标和优化点，以满足复杂的业务需求？ 可能大部分同

前端部署其实是一个非常严肃的问题，对于大型应用24小时都有人访问，如果你还是用覆盖式更新的方式部署，肯定会导致页面出错的情况发生，因此，这就涉及到先全量部署静态资源，再灰度部署页面的部署流程了。

随着devops的发展，前端部署变得越来越简单，可控性也越来越高，本文基于docker🐳+nginx+jenkins来实现前端自动化部署流程，具体实现效果为开发人员在本地开发，开发push提交代码到指定分支，😊自动触发jenkins进行持续集成和自动化部署。部署完成后会收到…

一. 概述 实验室每次项目发布测试时，都要手动本地打包好了然后上传到服务器，替换原来nginx下面的目录文件，十分麻烦和繁琐。这次就来优化一下，通过Dockerfile + Jenkins实现自动化部