我们有一个内部CI / CD服务器,它运行私有的GitLab。它具有我们NodeJS项目的源代码。我们希望运行CI / CD,并将其部署到我们的本地生产服务器上。 (假设我们使用的是master分支)。

这是我在互联网上找到的两种最常用的方法:


在生产服务器上运行git pull,运行所需的任何构建任务(npm install,minify等),然后重新启动服务
在CI / CD服务器上构建源代码,将构建的工件同步到生产服务器并重新启动

令人惊讶的是,我在Internet上找到的大多数示例都使用方法1。此方法要求生产服务器具有公共Internet访问权限,这在许多情况下可能是不可能的。

我的问题:方法1是真正将NodeJS应用程序部署到生产服务器的最佳方法?如果是,原因是什么?

评论

如果生产服务器无法访问Internet,则也无法rsync。如果使用物理介质,则可以使用其中任何一种方法;)

#1 楼

互联网上有很多不好的例子。做一个git pull来分发代码对于开发来说是很棒的,但是在实践中容易出现各种各样的问题。如果不仔细考虑负面影响,则不应将其用于生产部署。


当有人签出其他分支时会发生什么?当您继续git pull并没有任何新内容出现时,您会很难过。
如何验证计算机是否正在运行预期的版本?您可以从git获得此功能,但是对于大多数工件系统而言,它更容易。
如何释放到具有空缺网络的计算机上?对您来说,在专用网络上模拟git服务器将是一个有趣的时光。

我不确定npm用于工件的格式,但是备份它们可能也是一个好主意。 CI / CD服务器,并使用一组专用的机器来提供工件。如果您一次旋转100台计算机,您的CI / CD服务器会处理它还是倒下?隔离工件服务将避免CI / CD服务器被淹没并且在部署结束之前无用。

评论


我认为,git pull应该发生在prod分支上。如果要推送到另一个分支,则对于CI来说应该是非实体。但是,我同意在没有人工监督的情况下对产品进行CI可能太勇敢了。但这对于演示/测试系统来说是不可能的。

–peterh-恢复莫妮卡
19年3月11日在9:38



#2 楼

有些源代码管理系统也将其标榜为工件管理平台(例如Perforce / Helix),它们试图支持工作模式。但是git尤其不好。您需要做很多工作才能使git有效地支持代码开发和工件管理。我建议不要这样做,并为每个使用不同的系统。例如,JFrog Artifactory是一个很好的工具。在容器中交付代码并将docker hub用于工件存储是另一种出色的方法。甚至针对S3的一堆上传/下载脚本也比将工件存储在git中更好,因为如果您未正确设置解决方案,则可能会减慢开发人员的体验。