持续集成的NPM最佳实践

Question

我正在使用基于NPM的工具构建HTML5前端（grunt）。

我的持续集成构建过程的第一步之一是运行npm install。

npm install是SLOW。即使使用本地NPM代理缓存工件（Sonatype的Nexus 3），它仍然需要4分钟！

$> time npm install 
real 4m17.427s 
user 0m0.170s 
sys  0m0.290s 

---

如果我按照我的持续集成常用的最佳实践，我就从一个原始的SCM仓库启动和运行构建。这意味着每次CI构建将不得不执行新的npm install并承担4分钟的成本。

这是一个显着我的建造时间比例。我很不满意这个构建花了这么长时间。

---

另一种方法似乎是让node_modules保持在构建之间。但是，由于构建变得不稳定，我遇到了问题。

从package.json中删除依赖关系并不会从node_modules中删除它们，只需使用简单的npm install即可。我可以先用npm prune解决这个问题。

什么被认为是最佳实践在这里？

Answer 1

考虑到为了构建您必须安装新的软件包，您别无选择，只能致电安装。至于原始的，我坚信他们是指“构建”过程而不是“依赖管理”过程。

他们为什么不同？让我们通过一个例子来使其更加明显。

作为一名开发人员，当您第一次开始工作时，您必须“安装”可启用代码的“ ”软件。这通常是一次完成的。 之后，您可以开始编码。后者是“构建”部分 ，因为您正在为代码生成的每个功能生成值。从 不时，您可以通过删除，添加或更新工具列表来更新您的工具列表。

在这个例子中，每天安装你的工具，你开始编码之前到达工作将是地狱。

我建议你确保构建过程，这意味着生产工件（例如Jar），与依赖项安装过程分离。这意味着安装只需完成一次，即可顺利进行安装。你没有提到将要建造的东西，但是咕噜声可以确保其余部分的处理。

因此，我认为修剪和安装是一个很好的策略。你不应该担心第一次。把它想象成冷启动。任何使用子组件作为管道工作的系统都有这个“问题”。以汽车为例。当你开车时，它不会像在一小时后驾驶时那样节油。

Answer 2

安排日常工作以构建与您的依赖项相关的Docker容器。在最新的容器中运行您的CI作业。伪造CI作业的构建。

Answer 3

你应该在本地机器或本地网络离线安装npm包，您可以在这里找到一些提示=>Offline installation of npm packages

Answer 4

您在使用npm link甚至符号链接整个node_modules文件夹考虑？ 至少npm链接可用于您的开发依赖项，无论如何，您通常都希望在服务器上拥有受控的版本。这应该会加快一点。