从头开始创建Marvel iOS应用。 Travis，Danger和Fastlane ..

这是一系列文章的第三部分，涵盖了如何使用许多不同的Pod和工具从头开始创建iOS应用，从而使您的生活更轻松。 如果您错过了前面的部分，请检查它们的第一部分和第二部分。 在这篇文章中，我将讨论持续集成Danger和Fastlane。

该项目的源代码可在此存储库中找到。 我为此帖子创建了一个名为v0.3的标签，您 只需克隆存储库并切换到标签v0.3。

持续集成

持续集成（CI）是一门广泛的主题，其中涉及许多教程和书籍，但它是一个相对简单的概念。

在投入生产之前，应尽可能频繁地集成代码以及早发现错误。

如ThoughtsWorks网站中所定义。

“持续集成（CI）是一种开发实践，它要求开发人员每天多次将代码集成到共享存储库中。然后，每个签入都通过自动构建进行验证，从而使团队能够及早发现问题。通过定期集成，您可以快速检测错误，并更轻松地找到它们。”

“持续集成不会消除错误，但是确实可以使查找和删除错误变得更加容易。” Martin Fowler

在贝娄，您可以找到有关此主题的更多信息。

持续集成| ThoughtWorks
一家全球软件公司，专注于软件设计和交付。 我们提供专业的服务和产品，以及…… www.thoughtworks.com

基本上，我们必须有一些东西可以监视我们的存储库并运行自动构建。 测试 每次发生任何更改时都将部署过程。 那是CI服务器。 它们有各种形状和尺寸，您可以在这里找到它们的列表。 这篇博客文章将使用Travis，它是一个与github配合得很好的CI，并且是Github上托管的开源项目的主要选择。

特拉维斯

要使用travis，我们首先需要创建一个名为.travis.yml的文件

这就是全部，之后，您可以在每次将新的推送或PR添加到存储库时检查构建。

Travis可以像您期望的那样非常可定制，您可以找到许多不同的配置，它们具有有关此主题的大量文档。 我建议从一个简单的开始，并以此为基础。

同样值得一提的是，您可以看到在travis的脚本阶段中，我们仅调用两件事。

 脚本： 
  -快速通道测试 
  -捆绑执行程序的危险 

第一个：

  -快速通道测试 

是我们的自动化管道，是我们在上一篇博客文章中创建的自动化管道。 对于我们的示例，我们仅运行测试并生成覆盖率，但是我们可以做的还很多。 Fastlane可以处理和自动化您的整个管道，测试，构建，部署，生成和上传屏幕截图，发送通知等。 互联网上有许多涵盖所有这些主题的教程，您应该明确检查它们。 重要的是，一旦我们在开发人员机器上掌握了它，在CI中运行它就非常容易。 我们所需要的只是调用Fastlane的车道（例如：例如我们的“测试”），我们一切顺利。

注意事项：首先，请确保您的自动化管道在本地工作，它们带有CI，可以节省您的时间。

第二个：

  -捆绑执行程序的危险 

全部关于代码审查……让我们深入了解它。

危险系统..

Danger是由Orta，Felix Krause和其他出色开发人员创建的令人惊叹的新工具。

危险在CI流程中运行，使团队有机会自动执行常见的代码审查琐事。 这提供了构建中的另一个逻辑步骤，通过此Danger可以帮助减少日常代码检查中的死记硬背任务。 您可以使用“危险”来整理团队规范。 让人们去思考更棘手的问题。 她通过根据您使用Ruby脚本语言创建的规则将消息保留在PR中来实现此目的。 随着时间的流逝，随着规则的遵守，该消息将进行修改以反映代码审查的当前状态。
—危险系统

您可以在网站上找到初始的“入门”指南以及许多不同的DangerFile示例。 该文档涵盖了几乎所有需要的内容，我会提到一些我认为值得深思的地方。

还需要

• 在github上创建一个机器人用户。 您需要创建另一个用户才能用作漫游器
• 为Bot用户创建一个令牌，使其能够对我们的仓库进行评论。 在此处创建令牌。 对于开源项目，该漫游器应仅具有public_repo权限。
• 在travis上注册令牌，但记录不充分。

您需要添加一个名为DANGER_GITHUB_API_TOKEN的环境变量， 其中包含Bot令牌的值，也不要忘记在点击添加之前选择int “在构建日志中显示值” 。

危险文件

我正在为这个项目使用带有slatheranger插件的版本。 该插件允许在PR评论中使用肮脏的信息。 由Bruno Mazzo开发的Danger增强功能，他是一位非常有才华的开发人员，与我在Concrete Solutions一起工作。

您可以看到下面的Dangerfile波纹管：

在您的项目中配置所有这些并不难，但是在此过程中会遇到一些痛点，所以让我与您分享一些技巧。

交易技巧 ..

当我们谈论设置，配置项，测试，构建以及所有类似的事情时，有一些原则可以对我们的旅程有很大帮​​助：

• 婴儿脚步
• 从小处着手
• 到达所需位置后，立即提交（保存更改）并移至下一个所需位置。
• 不要尝试一次配置所有内容，这是失败的路线图。
• 不断测试您的配置。 进行但未经测试的更改是造成灾难的另一个秘诀。

遵循这些简单的原则可以节省很多麻烦。

危险只有招数..

• 创建另一个github帐户
• 分叉你的回购
• 使用此其他帐户发送PR。

我已经花了很多时间从存储库中的分支创建PR，并且没有被危险或Travis视为PR。 即使它们被github列为PR，但这还是有点令人困惑，至少我认为是这样。

包起来 ..

这结束了系列的第三篇文章。 接下来的内容将介绍如何使用Sketch（ 面向开发人员的 Sketch）制作更好的UI。 通过使用徽章，代码覆盖范围，图片和所有有趣而又有光泽的内容增强README，还将显示热点，使您的项目的github页面更光彩。

我们的回购将变得花哨的.. $）

与往常一样，任何想法，疑问或反馈都值得欢迎。 =）

附：如果您喜欢这篇文章，请在Twitter上分享，或在中级推荐，或两者都=）。 这确实有助于我吸引更多人。 非常感谢 ..

更新：**您可以在此处查看最后一部分。