第十四天：在 TeamCity 上执行程序码风格检查

昨天我们在专案里导入了 ktlint 这个用来检查程序码排版风格的套件，我们可以透过 Gradle 的两个指令 lintKotlin 及 formatKotlin 来检查（Lint）及重新排版（Format）专案的程序码。不过，虽然这个套件可以减少我们手动检查及修正程序码排版的工作，但这个指令需要人工来执行，根据我们的经验，只要是人工执行的指令就容易被忘记或忽略，长期下来这样的机制就形同虚设。该怎麽办？

别担心！这就是 TeamCity 出场的时刻啦！我们只要在 TeamCity 运行 Build 的步骤里安插一步执行 ktlint 程序码排版风格检查，只要没有通过这个检查，即便程序码能通过编译及测试，我们也视为建置失败，这样就能即早确保程序码品质有持续受到监控。

新增检查排版风格的 Build Step

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

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

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

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

设定 Build Step 的第一次事，就是要选择 Runner。Runner 您可以想像成是一个 Worker 的能力，TeamCity 支援非常多的 Runner，比方说 JVM 生态系常用的 ANT、Gradle、Maven、Kotlin Script，或是 .NET 生态系的 NuGet、NAnt、NUnit、OctopusDeploy 系列，或是 Node.js、Python、Rake 等也有，近期更受欢迎的应属 Docker、Docker Compose 所有。就算这些 Runner 都不符您意，还有终极的 Command Line、Power Shell 可以用，非常弹性！

以我们的练习专案来说，因为 ktlint 已经整合成 Gradle Plugin，所以我们 Runner Type 直接选 Gradle 即可。随後对应出来的 Step name 可以依自己的想法来设定，我们就先用「Check code style」吧！Gradle tasks 里写的就是要执行的 Task 指令，这边填入 lintKotlin。其他功能我们暂时都用不到，全部留空按 Save 储存即可。

用 TeamCity 执行程序码风格检查

我们先回到 IntelliJ IDEA，把程序码如同昨天练习一样搞乱排版後强制 Commit & Push，然後再回到 TeamCity 的 Shopping Cart 专案看结果，应该就会看到类似下图这样建置失败的画面。

点进 Build 详细页面就可以看到失败原因就是没有通过 ktlint 的排版风格检查。

我们再回到 IntelliJ IDEA，用 Gradle 的 formatKotlin 指令修正所有不符合排版风格范例的程序码後再重新 Commit & Push，看看这次 Build 是否能通过？

果然通过了！确认过这个检查机制後，以後只要有程序码推到 Repository，TeamCity 就会在 Build 的时候一并检查程序码风格，若没有通过就会发出警告。就算今天有在人本机开发时忘了或漏了检查，TeamCity 也能当最後一条防线，确保程序码库里的品质。

小结

今天我们将昨天学会的程序码排版风格检查工具 ktlint 搬到 TeamCity 上，让 TeamCity 可以做团队的第三只眼，随时看顾好程序码库的品质。这样的技巧也可以用在许多不同的面向，我们在接下来会以静态程序码检查、产生 API 文件等情境，跟大家介绍更多应用，敬请期待！