1. 我所经历的部署技术变迁

温馨提示

以下所有的内容，皆为本人所真实经历的内容，存在一定的个人主观性。

1.1 小作坊式部署

我刚开始参加工作时，是2016年。入职的是一家初创的外包公司，我简称Z公司。

Z公司主要开发后台系统，安卓客户端和iOS客户端，那时候用到的主要技术栈：

• 后端：SpringMVC、MyBatis、JSP、MySQL、Apache Tomcat。

• 前端：HTML、CSS、jQuery、Ajax。

• 其他：Eclipse、svn

那会不像现在，前后端分工这么明确。通常是一个人前端和后端的工作一起做。项目部署的时候，也没有什么自动化流程，直接连上服务器进行操作。如果是全量部署，将项目打成war包，放入Tomcat部署目录。如果是增量部署，进入Tomcat的部署目录，单个替换class文件或者JSP页面。

现在看来，这种操作虽然方便，但也非常危险。尤其是当增量更新修改的文件过多时，很容易弄错。而且会直接在服务器上执行rm操作，如果更新的人没有良好的删除前先备份的习惯，不小心删除了其他重要文件，那真的是一场灾难。

我将这种部署方式起个名吧，就叫小作坊式部署吧。

1.2 “人工智能”部署

时间来到了2019年初，我在第一家公司工作了三年后，移动互联网的红利已经消失的差不多了，彼时火热的共享经济也在慢慢退热。市面上做软件系统创业的需求也在降低，最终这家公司也走向了终点。我记得不知道从哪里看过一个观点，说90%的初创公司活不过三年，这个观点至少是在我身上验证了。

离开上家公司后，我入职了一家做智能语音及呼叫中心系统的公司。这家公司的规模是上家公司的好多倍，而且产品线也比较成熟，是一家自研系统进行销售的公司，以下我简称H公司吧。

H公司比Z公司人多，工作职责划分清晰。后台开发人员只负责开发后台代码，前端有专门的开发人员。更重要的是，后端开发人员，不需要自己手动部署程序了，有运维组的同事负责生产环境的运维和部署更新，而且后端开发人员没有连接生产环境服务器的权限。看上去一切都挺好是不是？

但是我为什么要称它为“人工智能”部署呢？

因为H公司归根到底，还是运维手工部署的，没有任何现代化的自动化部署工具。开发每次要更新软件版本时，都要先给运维组发送升级邮件。邮件的附件有份文件，一份是word格式的升级说明，大概内容是升级了哪些功能，升级步骤，注意事项等等；另一份是编译后的zip格式部署文件。运维升级时，其实只是按照开发给的升级步骤依次执行命令而已。只是运维比较专业，在升级之前，会先备份旧文件，一旦升级失败，就会把旧文件回滚恢复。

1.3 半自动化部署

时间又到了2021年。

在H公司工作了两年多的时间后，我入职了一家当初看起来非常有实力的初创公司，薪资比H公司高30%，我称它为Y公司吧。

Y公司和Z公司一样，都是初创公司，它们有很多相似的地方，当然结局也是相似的，这是后话了。

不同的是，当初在Z公司的时候，我还是一个懵懂的小菜鸟，在Y公司，已经算是一个比较有经验的开发人员了。因为是初创公司（刚刚成立三个月），正处在大量招人的初期阶段，技术方面还未流程化和制度化。我去的时候，研发部只招了一个技术总监，一个后台，两个前端，这个后台还是技术总监从上家公司带过来的。

技术总监人很不错（我们到现在还是很好的朋友），没有因为我不是他原来公司带过来的，就偏向另一个同事。他虽然挂的是技术总监的头衔，但其实更多的是精通业务，技术反而没有那么精通。因为人少，又缺乏管理，导致部署实施这块压根就没有任何人管。

Y公司走的是半外包，半自研项目的路子。当自研的产品开发出来后，销售将产品卖出去，然后由客户提供服务器，进行部署实施。我当时因为经历过前两个公司的部署流程，深感麻烦。怕以后公司项目多起来后，各个地方部署实施费时费力，就自己琢磨，将整个项目使用docker打包成镜像，然后再使用docker-compose来进行部署，这样大大简化了部署流程。

有Linux裸机安装过程序的人都知道，当一个程序依赖众多第三方程序的时候，部署起来有多麻烦。比如，Nginx、MySQL、RabbitMQ、Redis、MongoDB、Elasticsearch、MinIO、EMQX，……等等。光是这么多三方程序，安装配置完也得一天时间，如果Linux使用的不是特别熟练，那估计两天也装不完。如果使用docker，可能一到两个小时就能部署好。

为什么是半自动部署？ 因为还是有部分人工参与的。

部署流程是这样的，首先，我本地将系统打包成docker镜像，然后再编辑好docker-compose.yml文件。将本地的所有镜像，使用docker save命令将镜像导出，然后再编写shell安装脚本，将这些全部都打包成tar.gz格式的压缩包后，拷贝到客户的服务器上。安装部署时，先解压缩文件，再执行shell脚本进行一键安装。

1.4 自动化部署

自2023年开始，经济形势愈发严峻，Y公司肉眼可见的在走下坡路了。外部的项目在逐渐减少，公司内部也开始严抓考勤，迟到罚款，建立执行绩效政策，末位淘汰，搞的大家每天怨声载道，唉声叹气的。最终在2024年6月底，公司老板宣布解散，而我，也又一次被迫离职。一切好像回到了八年前，我从Z公司走的那天。

黄四郎

“彼时彼刻，恰如此时此刻”

《让子弹飞》 (opens new window)

2024年是我感觉找工作最难的一年，而且还是在年中，更是难上加难。经历了难熬的两个月，终于还是找到了比较合适的公司，我称它为X公司吧。

X公司是我经历过的自动化部署程度最高的公司，已经做到了完全自动化部署。

2. 自动化部署

2.1 整体流程图

2.2 流程说明

基于 GitLab、Jenkins、Docker、Harbor 以及 远程服务器 的 CI/CD（持续集成与持续部署）自动化流程，具体步骤如下：

1. 开发人员（Actor）提交代码
   • 开发人员在 GitLab 代码仓库中提交最新的代码。
2. Jenkins 触发自动化任务
   • GitLab 代码仓库发生变更后，Jenkins 自动检测到新代码，并触发 CI/CD 任务。
3. Jenkins 自动拉取最新代码
   • Jenkins 从 GitLab 仓库拉取最新的源代码。
4. Jenkins 构建 Docker 镜像
   • Jenkins 通过 Docker 打包构建应用程序的 Docker 镜像。
5. 推送 Docker 镜像到 Harbor
   • 构建完成的 Docker 镜像会被推送到 Harbor 镜像仓库，用于存储和管理。
6. 从 Harbor 拉取最新的 Docker 镜像
   • 部署服务器从 Harbor 拉取最新的 Docker 镜像，准备进行应用更新。
7. 执行远程 Shell 脚本
   • 通过远程 Shell 脚本，执行 容器更新 或 重启 操作。
8. 应用服务器完成更新
   • 服务器上的应用程序完成更新，新版本正式上线。

总结

该流程图展示了 GitLab + Jenkins + Docker + Harbor 组成的 自动化部署流程，可实现：

• 代码变更自动触发构建
• 自动打包并推送 Docker 镜像
• 服务器自动拉取新镜像并更新
• 实现 CI/CD 持续集成与部署，提高开发效率