使用SonarQube和Artifactory进行智能、基于指标的发布管理
发布或构建管理员必须做出的一些最重要的决定是是否通过CI管道来促进构建。为了使这些决策明智且合格，需要质量度量来指出构建中的问题。但有时，问题就在源头，为了检测这些问题，你需要SonarQube这样的工具。
SonarQube分析源代码以检测棘手的问题——比如bug、代码气味等等安全漏洞-影响代码质量。它还可以配置为根据一组测试结果来衡量这些结果质量闸门指标您定义其阈值，以帮助在构建或部署之前识别可能导致问题的代码。
作为你的二进制repository manager， JFrog Artifactory也是一个关键的部分CI / CD管道并且在确保所构建和部署的代码的安全性和质量方面发挥核心作用
这篇文章描述了如何配置Artifactory和SonarQube在CI/CD管道中一起工作，在低质量代码通过管道进入生产之前捕获构建。
元数据集成
TSonarQube和Artifactory之间的集成是通过将来自SonarQube的元数据(例如质量门故障)附加到Artifactory中托管的构建来实现的。该元数据可以在管道中进一步利用，以帮助决定是否应该在生产中推广和/或使用构建(相应的二进制文件)。
SonarQube分析可以添加到CI管道的一个阶段。通常，这将在您的CI服务器(如Jenkins、TravisCI或CircleCI)的配置中完成。
看看这个Git存储库这包括一个shell脚本artifactory-sonar.sh您的CI服务器可以使用它来调用SonarQube分析，并将其质量度量信息交付给Artifactory。
例如，如果您正在使用Jenkins，则可以添加artifactory-sonar.sh脚本到你的JenkinsFile中的后期构建阶段定义:
stage('Post Build') {sh -c "./artifactory-sonar.sh"}
shell脚本允许Artifactory捕获SonarQube分析(CeTaskId)的计算引擎标识符buildinfo．该标识符提供了对该构建中生成的SonarQube分析的质量门细节的访问。发布和构建管理人员可以使用该信息来决定(或自动化CI管道来决定)是否将构建提升到生产环境。
现在行动还是以后行动——你选择
Artifactory/SonarQube集成可以在两种工作模式下使用:等待(阻塞)模式(默认)或NOWAIT(阻塞)模式。
等待模式
在等待模式下，集成等待SonarQube分析完成，然后决定是否让构建失败。
对于构建时间短或构建时间无关紧要的项目，建议使用此模式。
如前所述，这是将该检查添加到JenkinsFile的后期构建阶段的方法。
stage('Post Build') {sh -c "./artifactory-sonar.sh"}
如果您希望始终覆盖SonarQube质量度量，以使其不会构建失败，请使用该参数调用脚本假．
stage('Post Build') {sh -c "./artifactory-sonar.sh false"}
NOWAIT模式
在NOWAIT模式下，脚本不会等待SonarQube分析完成，而是只存储分析的计算引擎标识符(CeTaskId)作为Artifactory的buildinfo的一部分。该信息可以稍后在管道中用于查询SonarQube，以获得该构建的质量门状态。
这种模式推荐用于大型项目，在这些项目中，让构建等待SonarQube分析是不可接受的。
要在无等待模式下调用，执行:
stage('Post Build') {export WAIT_FOR_ANALYSIS=false;/ artifactory-sonar.sh}。
您可以下载并使用此脚本作为参考，但是，您可能需要根据自己的需要对其进行修改，因为管道和约定因公司而异。
有关实现的进一步详细信息，请参见自述文件项目内容:
你准备好在Artifactory中使用一些SonarQube质量门指标了吗?
