我尝试配置一种正确的方法来与Angular CLI进行持续集成。
为了好玩，我在Windows中管理我的Jenkins，并使用Angular CLI创建了一个测试项目。
这个项目绑定到Bitbucket远程，我使用Sourcetree作为版本控制系统。
但我对应用正确的工作流程有很多疑问，因为我很困惑。
1） Angular CLI允许我们使用命令ng build构建项目。它创建一个名为dist的文件夹。好的，.gitignore会忽略此文件夹，为什么？
我的意思是，我需要这个文件夹，因为我的Jenkins作业使用它来在我的域中通过FTP部署它，不是吗？如果忽略该文件夹，它将无法在远程bitbucket中使用，因此Jenkins无法使用。
2） Jenkins用于执行部署的某些任务。它不应该被用来做ng build这样的事情吗？在我看来，连续，缩小等......应该融入工作任务中，我做对了吗？据此分裂＆＃34; build＆＃34;任务？
我需要澄清一下。这是我第一次这样做。
谢谢你。
答案 0 :(得分：2)
1）将dist文件夹置于源代码管理之下并不是最佳做法。 dist文件夹包含ng build的输出，这意味着每次运行ng build时，dist文件夹的内容都会发生变化。如果您碰巧将其置于源代码管理之下，则会导致定期合并冲突。构建（任何构建）的目的是生成此文件夹。您的CI作业也是构建，因此它也会生成dist文件夹
特别是Jenkins为您配置的每个作业都有一个单独的“工作空间”。在启动CI作业时，将执行工作空间的更新（取决于您的配置和使用的VCS）。然后使用新源来运行构建，就像在本地计算机上一样。 ng build清除dist文件夹并创建一个新文件夹
在构建完成之前，您已准备好以您认为合适的任何方式部署dist文件夹（zip it - ＆gt;通过FTP / SSH发送 - > gt; inflate - ＆gt;执行必要的任务以获取所需内容通过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工作管道。一个工作是构建，捆绑和归档您的项目，第二个（下游）工作要部署。
希望这有点帮助:)。
答案 1 :(得分：0)
构建工件，生成的代码，编译的类......等。将 NOT 源代码控制为最佳做法。源代码是您的真实来源，因此从源代码控制中忽略您可以从中构建/预处理的任何内容。通常，您的构建管道中的作业会打包您的应用程序/工件，并将其部署到某个存储库以供将来使用或交付，或通过Jenkins存档。
中，您可以指定可以手动或自动触发的下游作业，具体取决于配置。我个人更喜欢有一个基本的初始构建作业，当有推送时，SCM会通过服务挂钩触发它，它首先构建工件/应用程序，并将构建工件存档到工件存储库。您可以拥有一个可以部署构建工件的下游传递作业，在这里您可以根据您的使用情况使用多个Jenkins插件进行部署。顺便说一下，一旦在构建作业中设置了上游/下游关系，就可以通过选择初始作业来创建管道视图。它创建了一个很好的管道视图。
我建议您也查看Jenkis downstream job fails to find upstream artifacts stackoverflow问题。我希望这能回答你的问题。