在给新项目接入扫描、迁移流水线、调整账号权限，还有令牌到期了以后，常常会碰到一类问题，那就是SonarQube的扫描令牌，到底应该怎么去配置它，还有，一旦那个令牌失效了，为什么项目就没法再继续分析了，SonarQube的扫描令牌，它可不是一串普普通通的字符串，这个东西，代表的是某一个用户，或者是某一个项目，它所拥有的分析权限，按照官方文档的说明，令牌是可以被拿来执行分析用的，用的时候，不需要把真实的账号密码给暴露出去；但是呢，在跑分析的时候，那个令牌所对应的用户，他必须得拥有，对这个项目的执行分析的权限。

在一条流水线被长期接入之后，经常会出现一类问题，就是SonarQube里面的历史分析记录，该怎么样去清理一下，还有它的数据库体积，要是变得太大了，又该怎么去处理，项目每天都在那跑扫描、分支被反反复复地创建、版本号也在不停地变化，这么一来，数据库就会慢慢地变大，SonarQube它自己，其实是有一套后台维护机制的，它会在新的分析被执行完了以后，去清理掉一部分旧的数据、旧的历史快照、PR的分析，还有分支的记录，靠着这个，来减缓数据库的膨胀，官方的文档里也说明了，那些旧的分析，是不会被完完整整地一直保留着的，不然的话，数据库就会变得臃肿不堪。

在企业想要统一账号体系的时候，有两件事是需要处理的，一件是怎么把SonarQube接入到LDAP的登录里去，另一件是用户和组的映射关系，又要怎么去配置好，SonarQube是可以把认证这件事，委托给LDAP或者是Active Directory去做的，当一个用户第一次登录成功了以后，SonarQube里面就会自动地给他建好一个账号，等到后面他再登录的时候，也都会去同步他的用户名、邮箱，还有一些可以选择的组的关系，按照官方文档给出的说明，去接入LDAP这件事，主要是靠在安装目录下面，去修改conf文件夹里面的配置文件来完成的，等改完了以后再去重启一下服务，然后通过看日志，来确认跟LDAP的连接是不是真的通了。

在代码扫描刚刚落地的时候，有两个问题是挺常碰到的，一个是SonarQube扫出来的问题，到底要怎么去分配给具体的人来处理，另一个是，这些问题它的状态变来变去，又要怎么去管，扫描出来的结果一多，要是没有个明确的负责人，那些问题就会长时间地挂在列表里面；可要是大家随便地就把状态给改成了已接受，或者是误报，那到了后面，再去搞质量门禁、版本复盘，还有审计说明的时候，就会很难说得清楚了。SonarQube在分析的时候，它会试着把新发现的问题，自动分配给，最后改过那一行代码的人，但这有个前提，就是代码提交时候用的那个账号，得能跟SonarQube里面的用户，关联得上；要是关联不上，那它就会去用项目里设好的那个默认处理人。

如果不想让`target`、`dist`、`build`、`generated`、`node_modules`这类目录被当成手写的代码来分析，就得靠SonarQube的排除规则，它支持通过路径匹配的方式，去把那些文件给排除掉，这个设置，既可以在项目的页面上去完成，也可以写在CI/CD主机上的扫描参数里面；不过有一点要注意，要是同一个参数，在两个地方都设置了，那CI/CD里的参数，是会优先于页面上的设置的。

SonarQube的质量配置文件，它本质上就是决定了，某一种语言在跑代码分析的时候，到底会启用哪些规则，一个项目扫描出来的那些问题，也会受到它当前绑定的那个配置文件的影响，按照SonarQube的文档说明，质量配置文件，就是用来定义在分析代码的时候，要应用的那一套规则集合的，而且每一种语言，都可以有它自己专属的配置文件。

做SonarQube权限管理时，最容易乱的地方，不是按钮找不到，而是把全局权限、项目权限和令牌管理混成了一层。SonarSource官方文档把这条线分得很清楚，全局权限在【Administration】【Security】【Global Permissions】里管理，项目相关权限更多通过权限模板和项目级权限页来落地；而Token又是另一条独立链路，既有用户自己生成和轮换的分析令牌，也有管理员代用户生成或撤销的用户令牌。换句话说，权限和Token虽然都在安全域里，但真正稳的做法是分层治理。

很多团队一上来就先往`.gitlab-ci.yml`里塞扫描命令，结果跑是能跑，后面要么MR不出结果，要么质量门禁没法拦合并，要么分支和MR参数还互相打架。SonarQube官方文档把这条链路拆得很清楚，GitLab CI集成至少有三步，先在SonarQube里把项目建好并和GitLab关联，再把分析任务接进GitLab CI/CD，最后再让MR分析和质量门禁结果回写到GitLab。真正稳的做法，不是先写脚本，而是先把项目绑定、扫描入口和MR触发条件摆顺。

做SonarQube扫描时，很多人一看到失败就先去改项目配置，结果改了半天，真正的问题其实可能在令牌、服务器地址、证书、代理，或者服务器后台任务本身。Sonar官方文档把这件事拆得很清楚：分析参数里有一批必须在CI/CD主机上设置的基础项，分析失败时又要分别看Scanner侧和Server侧的日志；如果网络链路里还有代理、HTTPS或自签名证书，排查顺序还会再往网络层延伸。把这些层次分开看，扫描失败这件事通常会比一上来就反复重跑更容易收住。

SonarQube扫描慢，很多时候不是服务器本身有问题，而是把三类事情混在了一起，一类是分析范围太大，一类是缓存没有真正用起来，还有一类是并发开法和语言插件本身的机制没对上。SonarSource官方文档写得很清楚，增量分析里的analysis cache是按分支管理的，扫描前会先下载缓存，扫描后再按规则回写；但并发并不是一个所有语言通用的总开关，而是由不同语言分析器分别控制。也就是说，先分清你慢在范围、缓存，还是线程，后面才调得准。