计算机网络把各地的计算机连接了起来，只要有一台可以上网的终端，比如手机、电脑，就可以访问互联网上任何一台服务器的资源（包括静态资源和动态的服务）。

作为开发者的我们，就是这些资源、服务的提供者，把资源上传到服务器，并把服务跑起来的过程就叫做部署。

代码部分的部署，需要先经过构建，也就是编译打包的过程，把产物传到服务器。

最原始的部署方式就是在本地进行 build，然后把产物通过 FTP 或者 scp（基于 SSH 的远程拷贝文件拷贝） 传到服务器上，如果是后端代码还需要重启下服务。

每个人单独构建上传，这样不好管理，也容易冲突，所以现在都会用专门的平台来做这件事构建和部署，比如 jenkins。

我们代码会提交到 gitlab 等代码库，然后 jenkins 从这些代码库里把代码下载下来进行 build，再把产物上传到服务器上。

流程和直接在本地构建上传差不多，只不过这样方便管理冲突、历史等，还可以跨项目复用一些东西。

构建、部署的过程最开始是通过 shell 来写，但写那个的要求还是很高的。后来就支持了可视化的编排，可以被编排的这个构建、部署的流程叫做流水线 pipeline。

比如这是 jenkins 的 pipeline 的界面：

除了构建、部署外，也可以加入一些自动化测试、静态代码检查等任务。

这种自动化了的构建、部署流程就叫做 CI（持续集成）、CD（持续部署）。

我们现在还是通过 scp / FTP 来上传代码做的部署，但是不同代码的运行环境是不同的，比如 Node.js 服务需要安装 node，Java 服务需要安装 JRE 等，只把代码传上去并不一定能跑起来。

那怎么办呢？怎么保证部署的代码运行在正确的环境？

把环境也给管理起来，作为部署信息的一部分不就行了？

现在流行的容器技术就是做这个的，比如 docker，可以把环境信息和服务启动方式放到 dockerfile 里，build 产生一个镜像 image，之后直接部署这个 docker image 就行。