使用 Angular CLI 和 Jenkins 执行持续集成的好方法

Question

我尝试配置正确的方式来执行与 Angular CLI 的持续集成。

只是为了好玩，我在 Windows 中管理我的 Jenkins，并使用 Angular CLI 创建了一个测试项目。

这个项目绑定到 Bitbucket 远程，我使用 Sourcetree 作为版本控制系统。

但我对应用正确的工作流程有很多疑问，因为我很困惑。

1) Angular CLI 允许我们使用命令ng build 构建项目。它创建一个名为dist 的文件夹。好的，但是这个文件夹在.gitignore 中被忽略了，为什么？ 我的意思是，我需要这个文件夹，因为我的 Jenkins 工作使用它在我的域中跨 FTP 部署它，不是吗？如果该文件夹被忽略，它将在远程 bitbucket 中不可用，因此 Jenkins 无法使用。

2) Jenkins 用于执行一些部署任务。它不应该被用来做像ng build 一样的事情吗？在我看来，concat、minification 等应该整合到工作任务中，我说的对吗？根据这个拆分“构建”任务？

我需要澄清一下。这是我第一次这样做。

谢谢。

Answer 1

1) 将dist 文件夹置于源代码控制之下确实不是最佳做法。 dist 文件夹包含 ng build 的输出，这意味着每次运行 ng build 时，dist 文件夹的内容都会发生变化。如果您碰巧将其置于源代码控制之下，则会导致定期合并冲突。生成此文件夹是构建（任何构建）的目的。您的 CI 作业也是一个构建，因此它还会生成 dist 文件夹。
特别是 Jenkins 为您配置的每个作业都有一个单独的“工作区”。在启动 CI 作业时，将执行工作区更新（取决于您的配置和使用的 VCS）。然后像在本地机器上一样，使用新的源代码来运行构建。 ng build 清理 dist 文件夹并创建一个新文件夹。
在构建完成时，您已准备好以您认为合适的任何方式部署 dist 文件夹（压缩它 -> 通过 FTP/SSH 发送它 -> 膨胀 -> 执行必要的任务以通过您的HTTP 服务器）。

2) 连接、缩小和捆绑确实应该由您的 CI 工作执行。值得庆幸的是，ng cli 能够为您完成所有这些工作。运行ng build --prod。 --prod 开关将启用捆绑包缩小和 AOT 编译，为您的发行版生成尽可能小的捆绑包。
一个好主意是添加一个步骤来 gzip 您的 .css 和 .js 文件，并配置您的 HTTP 服务器以提供捆绑包的 gzip 版本（如果要求）（Accept-Encoding: gzip）。 对于 Windows 机器，这将完成这项工作：
cd dist FOR %%i IN (*.js) DO "C:\Program Files\7-Zip\7za.exe" a "%%~ni.js.gz" "%%i" FOR %%i IN (*.css) DO "C:\Program Files\7-Zip\7za.exe" a "%%~ni.css.gz" "%%i"

正如@burcakulug 的回答中提到的，如果您有一个工件管理系统，您应该考虑建立一个 Jenkins 工作管道。一项工作是构建、捆绑和归档您的项目，另一项（下游）工作需要部署。

希望这会有所帮助:)。

Answer 2

1. 构建工件、生成的代码、编译的类...等。 不作为最佳做法进行源代码控制。源代码是您的真实来源，因此您可以从那里构建/预处理的任何内容都会被源代码控制忽略。通常，您构建管道中的作业会打包您的应用程序/工件并将其部署到某个存储库以供将来使用或交付，或通过 Jenkins 存档。

2. 在 Jenkins 中，您可以根据配置指定可以手动或自动触发的下游作业。我个人更喜欢有一个基本的初始构建作业，它在有推送时通过服务挂钩由 SCM 触发，它首先构建工件/应用程序，并将构建工件存档到工件存储库。你可以有一个下游交付工作来部署构建工件，在这里你可以根据你的用例利用几个 Jenkins 插件进行部署。顺便说一句，在构建作业中设置上游/下游关系后，您可以通过选择初始作业来创建管道视图。它创建了一个很好的管道视图。

我建议你也看看Jenkis downstream job fails to find upstream artifactsstackoverflow 问题。我希望这能回答你的问题。