YNAP上的SwiftLint和Danger自动执行iOS代码评论

在YOOX NET-A-PORTER GROUP（YNAP），我们使用Swift构建iOS应用。

Swift是一种现代，快速且类型安全的编程语言。 在iOS应用开发中，获取有关Swift代码的即时反馈至关重要。

作为一种类型安全的语言，Swift上的大多数安全检查均由Swift编译器在编译阶段完成。 但是，有许多干净的编码实践，例如语法检查，样式等，还需要执行。

在本文中，我们将探讨如何在YNAP的iOS应用中使用Danger，Swiftlint和Travis CI自动执行大多数Swift代码检查过程。

代码审查的过程可能很困难，而对于Swift作为一种新的编程语言而言，这尤其困难。

SwiftLint是事实上的工具，它通过执行适用于特定团队或项目的规则来整理Swift源代码。 我们使用了之前博客文章中提到的一些最佳实践，在TravisCI（即我们的持续集成（CI）服务器）上实现了SwiftLint。

我们的SwiftLint配置具有一些严格的规则，我们曾经在Xcode构建阶段中运行SwiftLint，以便开发人员可以在开发时看到Xcode本身中的警告或错误。 但是，与其等到CI构建到达Xcode构建阶段脚本，还不如等到构建开始时就对代码进行反馈。

为此，我们需要一种在CI构建运行时提供早期反馈的机制。 我们还希望通过pull请求可以看到SwiftLint提供的反馈，以便我们立即采取行动。

这就是危险出现的地方。

Danger是一种在CI上运行的工具，用于处理所有琐碎的代码检查任务，例如错字，空格，换行符等。它还使我们能够超越基础知识，并添加更多项目特定检查或执行测试或文档作为其中的一部分。拉取请求。

在此处的官方网站上有很多关于如何开始使用Danger的出色文档。

规则需要在配置文件（称为Dangerfile）中列出。 规则可以用Ruby，JavaScript或Swift编写。 但是，Swift实现相对较新，我们希望使用脚本语言在CI上的预配置环境中运行Danger。

幸运的是，Travis CI macOS映像随附了预装的Ruby和RVM，从而使安装Danger和大多数Danger插件（例如Rubygems）更加容易。 因此，我们决定用Ruby编写Dangerfile规则，以便在实际开始构建之前就可以在Travis CI上明确运行它们。 有了Danger，我们可以按此处所述配置各种规则，但是我们遵循了Swift和iOS特定的规则。

• 检查较大的请求，尤其是如果有超过500行代码
• 检查是否已将单元测试作为“拉取请求”的一部分添加，如果应用程序代码已更改
• 检查“拉取请求”上是否有标签
• 检查Podfile或Podfile.lock已更新？ 如果是这样，则忽略该较大的请求

这些是Danger轻松实现的非常基本的检查-但其真正功能来自于Danger的SwiftLint插件。 此插件将所有SwiftLint规则应用于“拉取请求”中的代码审查过程，从而使Danger可以在发现SwiftLint警告或错误的任何地方自动对“拉取请求”进行注释。

现在，我们已经介绍了Danger和SwiftLint插件的基础知识，下面我们来讨论如何在Travis CI服务器上进行设置。 我们需要以下各项来在Travis CI上设置Danger。

• GitHub上的专用Bot帐户/个人访问令牌

我们在GitHub上创建了一个专用的机器人帐户，该帐户可以对“拉取请求”进行评论。 为了做到这一点，我们还需要创建一个具有写访问权限的Github个人访问令牌，使Bot能够对拉取请求进行注释。 可以在iOS项目的Travis CI设置中将此个人访问令牌配置为环境变量DANGER_GITHUB_API_TOKEN 。

• 在Travis CI上安装Danger和SwiftLint Danger插件

有了Github访问令牌后，接下来我们更新了Travis配置.travis.yml以在before_script阶段安装Danger和SwiftLint Danger插件，如下所示。

由于Travis CI的macOS映像已使用Ruby和RVM进行了预配置，因此我们只需要在脚本中安装Rubygems即可安装Danger和Danger的SwiftLint插件。

注意：如此处文档所述，危险可在任何CI服务器上运行

• 在Travis CI上运行危险

安装完成后，仅使用danger命令执行所有规则即可在Travis CI上运行Danger相当容易。 这将运行在Dangerfile为我们的项目配置的所有检查。

但是，如果您使用Travis CI的构建矩阵功能并行运行多个构建，则事情可能会变得棘手。 使用构建矩阵，Danger将在每个并行构建上执行，从而导致对“拉取请求”的多个注释。

为了克服这个问题，并确保Danger仅对每个矩阵的Pull Requests注释一次，我们创建了一个条件构建执行，其变量环境称为

为了克服这个问题，确保危险仅在“拉取请求”操作矩阵中注释一次。 我们通过在Travis CI中使用环境变量DANGER="ALLOW"有条件地执行构建来实现这一目标。 配置看起来像这样

  before_script： 
  -gem install fastlane --no-ri --no-rdoc --no-document 
  -gem install危险--no-ri --no-rdoc --no-document 
  -gem installanger-swiftlint --no-ri --no-rdoc --no-document 
  -如果[$ DANGER ==“ ALLOW”]; 然后 
 危险; 
  ./Pods/SwiftLint/swiftlint lint --config .swiftlint-ci.yml; 
 科幻 
 矩阵： 
  fast_finish：是 
 包括： 
  -osx_image：xcode10 
  env：CI_BUILD_TARGET ='nap'CI_DEVICE ='iPhone X（12.0）'DANGER =“ ALLOW” 
  -osx_image：xcode10 
  env：CI_BUILD_TARGET ='nap'CI_DEVICE ='iPad Air 2（12.0）' 

如您所见，我们仅在构建矩阵中设置了变量DANGER =“ ALLOW” 。 同样，在before_script阶段中，我们在设置了环境变量时设置了Danger的条件执行。 通过这样做，我们可以避免多个危险评论。

就是这样！ 我们已将Danger配置为在Travis CI服务器上运行。

现在，让我们看看Danger如何进行自动代码审查，以及它如何帮助团队快速修复代码错误。 每当开发人员创建“拉取请求”时，都会在Travis CI和Danger上的构建触发器作为before_script阶段的一部分运行。 危险运行完毕后，它将在“拉取请求”中添加注释，或在“拉取请求”中报告任何问题。 例如，如果我们忘记添加单元测试，那么我们会在“拉取请求”中得到通知

危险还将通知我们有关代码样式的问题，例如空格，多余的行等。

现在我们有一个针对Swift的全自动代码审查过程。 我们的Github机器人会审核我们所有的请求请求，以及机器人报告的任何注释，这些注释需要作为请求请求的一部分进行修复。 一旦Danger满意并且其他开发人员完成了逻辑审查，则Pull Request得到批准。

我们从自动化代码审查中获得了很多好处，包括：

• 开发人员不再需要花时间在“拉取请求”上进行低级注释，而可以集中精力进行更重要，更详细的逻辑代码审查。 这种自动化方法节省了开发人员在代码审查过程中的时间
• Swift代码中没有引入新的警告或问题，从而提高了代码质量
• 当我们添加了一条规则来检查是否在请求请求中添加了测试时，我们的代码覆盖率每天都在提高，这增强了开发人员的信心，即我们没有在代码中建立任何技术负担，并且我们已经过了充分的测试码

在YNAP，通过结合使用SwiftLint Danger插件和Travis CI，我们在应用中实现了更快的代码审查并提高了代码质量。

我们已经走了很长一段路，但是当然，我们还没有完成–下一步：添加更严格的规则以使我们的代码更健壮和可靠！

您对自动执行iOS代码审查有什么经验？ 分享以下评论。