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

Question

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

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

该项目绑定到Bitbucket remote，我使用Sourcetree作为版本控制系统。

但我有多个关于正确的工作流程的问题，因为我很困惑。

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

2） Jenkins用于执行部署任务。它不应该用来做像ng build一样的东西吗？在我看来，连接，缩小等应该被整合到工作任务中，我是对的吗？据此分割“构建”任务？

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

谢谢你。

Answer 1

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

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

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

Answer 2

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编译，为您的发行版生成最小可能的捆绑包。
如果询问（Accept-Encoding: gzip），一个好主意是添加一个步骤来gzip你的.css和.js文件，并配置你的HTTP服务器来服务捆绑的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的答复中提到，如果你在的地方有一个工件管理系统，您应考虑设立一个詹金斯作业流水线。一个工作是构建，捆绑和归档项目，第二个（下游）工作要部署。

希望这有助于一点:)。