问题描述
我们有一个内部的 CI/CD 服务器，运行着私有的 GitLab。它拥有我们 NodeJS 项目的源代码。我们希望运行 CI/CD，并将其部署到我们的内部生产服务器上（假设我们使用 master 分支）。
以下是我在互联网上找到的两种最常见的方法：
1. 在生产服务器上运行 git pull，运行所需的构建任务（如 npm install、压缩等），然后重新启动服务。
2. 在 CI/CD 服务器上构建源代码，将构建好的构件通过 rsync 同步到生产服务器上，然后重新启动服务。
令人惊讶的是，我在互联网上找到的大多数示例都使用了方法1。这种方法要求生产服务器具有公共互联网访问权限，而这在许多情况下可能是不可能的。
我的问题是：方法1真的是将 NodeJS 应用程序部署到生产服务器的最佳方式吗？如果是，原因是什么？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在实际生产环境中，直接使用 git pull 分发代码是不可取的，因为它存在一些问题。因此，我们不建议将其用于生产部署，除非仔细考虑了负面影响。
以下是一些使用 git pull 的问题：
1. 当有人切换到不同的分支时会发生什么？如果你不断地执行 git pull，但没有任何新的内容出现，你会感到沮丧。
2. 如何验证机器是否运行了预期的版本？你可以从 git 中获取这些信息，但使用大多数构件系统会更容易。
3. 如何在没有互联网访问权限的网络上部署？在私有网络上模拟你的 git 服务器将会是一件有趣的事情。
此外，对于 npm 使用的构件，最好将它们从 CI/CD 服务器备份，并使用专用的机器来提供构件服务。如果一次启动了100台机器，你的 CI/CD 服务器能处理吗？将构件服务隔离开来，可以避免 CI/CD 服务器被淹没并在部署结束之前无法使用。
方案2
有一些源代码管理系统也兼具构件管理平台的功能（例如 Perforce/Helix），它们试图支持这种工作模式。但是，git 在这方面特别不好。你需要做很多工作，才能使 git 同时高效地支持代码开发和构件管理。我们建议不要这样做，而是为每个任务使用不同的系统。例如，JFrog Artifactory 是一个很好的工具，可以用于构件管理。使用容器交付代码，并使用 Docker Hub 作为构件存储库，也是一个很好的方法。即使是一些针对 S3 的上传/下载脚本，也比将构件存储在 git 中要好，因为如果你没有正确设置解决方案，可能会明显降低开发人员的体验。
以上是两种常见的部署方式。根据实际情况和需求，选择适合自己的方式进行部署。
总结
在部署 NodeJS 应用程序到生产服务器时，直接使用 git pull 是不推荐的，因为它存在一些问题。相比之下，将构建好的构件通过 rsync 同步到生产服务器上并重新启动服务是更好的选择。此外，还可以考虑使用专门的构件管理工具，如 JFrog Artifactory，或使用容器交付代码并使用 Docker Hub 作为构件存储库。选择适合自己的部署方式，可以提高部署的效率和可靠性。
注：以上解决方案仅供参考，具体部署方式应根据实际情况和需求进行选择。