第十六天：在 TeamCity 上执行静态分析

昨天我们在专案里导入了 detekt 静态分析套件，只要执行 $ gradle detekt 就可以扫描整个程序码库，及早找出浅在问题。我们也介绍了如何在 IntelliJ IDEA 安装 detekt Plugin，让我们在写程序码的过程中就可以即时的看到扫描结果。而同样的技巧我们也可以用在 TeamCity 上，只要新增一个 Build Step 即可。

新增静态分析的 Build Step

先请登入 TeamCity Server，选择 Shopping Cart 专案页面，点选左上角 Edit project 进入专案设定。

选择画面中间 Build Configurations 表格里 Build 最右边的 Edit 进入编辑功能。

选择左边侧边栏的 Build Step，准备新增一个建置步骤。

在 Build Step 设定页，点选 Add build step 新增一个建置步骤。

用我们已经学会 Gradle Runner，Step name 就命名为「Static Analysis」，Gradle task 就是 detekt，其他功能留空按 Save 储存即可。

调整 Build Step 的执行顺序

目前我们总共有 3 个 Build Step，第一个 Build Step 执行了 clean 和 build、第二个 Step 是 lintKotlin、第三个则是 detekt。但假如希望在 Build 之前先做 Linter 及 Static Analysis 的检查呢？这时我们可以调整 Build Step 的执行顺序来达成这个需求。

首先我想把第一个 Build Step 的动作拆开，先修改第一个 Build Step，里面的 Gradle 指令只留下 build，接着再新增一个 Build Step，Step name 就命名为「Clean」，Gradle task 就是 clean，其他功能留空按 Save 储存即可。

回到 Build Steps 设定页，点击 Reorder build steps 按钮，这时会弹出一个调整视窗，拖曳每一个项目左边三条线的图示就可以调整 Step 的顺序，完成後按 Apply 就套用完成了。

用 TeamCity 执行静态分析

回到 Shopping Cart 专案的 Build 页面，按下右上角的 Run 按钮，测试一下调整完的 Build 流程。

因为昨天我们故意留下 Wildcard Import 的问题，所以上面的 Build 会失败，我们点开 Build 的详细资讯，点到 Build Log 页可以看到这次 Build 失败的原因就是卡在 Static Analysis 这一个 Step。

回到 IntelliJ IDEA，依照昨天学会的作法，用 Option+Enter 来汇入完整的 Package 名称後，重新 Commit & Push，触发 TeamCity 再跑一次 Build。

这次就成功通过静态分析了！以後每当程序码库有变更时，TeamCity 就会自动触发排版风格检查、静态分析及测试，有这三大利器的保护，我们的程序码品质就受到坚实的保障。

小结

今天将 detekt 与前面学过的 Build Step 结合，也再介绍了调整 Build Step 顺序的方式，相信大家对建置设定会更熟悉。不过，每次我们把程序码变更推送到 GitHub 後，都要自己跑去 TeamCity 看结果还蛮花时间的。对开发者来说，其实只有 Build 失败时才需要知道结果，不然跑去 Web UI 看通过的 Log 其实没有意义，是不是有什麽方式可以在 Build 失败时主动通知我们呢？

没错！我们明天就来介绍 TeamCity 的通知功能，敬请期待！