Tag: 持续集成

企业持续交付YOOX NET-A-PORTER GROUP移动框架: 在移动应用程序开发中，可靠的架构模式在更快地构建应用程序中起着重要作用。因此，为了确保多个应用程序中现有代码的质量和可重复使用性，公司开始构建可重复使用的软件开发工具包（通常称为SDK）来开发移动应用程序。对于iOS，Apple已经创建了无数SDK，供应用程序开发人员构建应用程序，但公司仍需要构建自己的自定义iOS SDK，以在其应用程序中共享产品特定的通用代码。为了加快YOOX NET-A-PORTER GROUP（YNAP）的iOS应用开发速度，我们构建了通用的iOS库，这些库可以在NET-A-PORTER，MR PORTER，YOOX，THE OUTNET和30+以上的多个iOS应用之间共享我们为其经营数字商店的品牌。主要的iOS SDK之一是我们的客户端应用程序与后端API之间的一层，在本文中，我们将其称为“ iOS-SDK”。什么是iOS-SDK YNAP在App Store上提供了许多iOS应用程序以及为我们的同事服务的许多其他企业应用程序。我们希望为同事们反映客户的经验，同时减少重复编码。为此，我们决定构建一个通用的iOS-SDK，以方便在我们的客户和企业应用程序之间共享。这也使我们可以通过在方法和返回类型方面定义一组行为来简化构建过程。然后，使用SDK的人只需为每个应用实现适配器。这意味着iOS-SDK是iOS库的集合，可使用CocoaPods或Carthage轻松分发。我们仅用Swift编写了该库，并且它具有一个内置的示例应用程序，可让我们测试特定于客户端的功能。为什么我们需要iOS-SDK的持续集成和持续交付由于iOS-SDK代码可能会影响多个客户端应用程序，因此必须确保iOS-SDK的代码质量满足所有受支持的应用程序的要求。为此，定期运行可靠的自动化测试非常重要，以确保一个客户端的代码更改不会对其他客户端产生负面影响。为此，我们需要持续集成（CI）来获取对iOS-SDK代码库所做的任何更改的即时反馈，并需要持续交付（CD）来相应地更新客户端应用程序。通过将CI / CD添加到iOS-SDK，我们可以获得有关Swift代码更新的早期反馈，并定期在客户端应用中测试新功能。为SDK实施CI / CD实践与对普通iOS应用同样重要。我们开始通过构建自动化，自定义脚本和使用Travis CI功能在iOS-SDK库上实现CI / CD。我们的iOS-SDK CI / CD火箭现已准备好发射。 iOS-SDK部署自动化我们的iOS-SDK是一个Swift库，我们使用CocoaPods或Carthage分发它。手动部署iOS-SDK库是一个耗时，重复（而且很无聊！）的过程。以前，每当我们要发布新版本的iOS-SDK时，开发人员都需要经历手动过程。我们需要克服这一点，并开始寻找可以执行以下操作的自动发布过程：当源代码在Master分支中合并后，会自动构建该库的新版本，运行所有自动化测试并自动使用Podfile或Cartfile提到的版本创建标签使用Github Changelog.md发行说明自动制作该库的Github版本将库的新版本推送到YNAP的专用Cocoapods存储库，以便我们可以从专用存储库下载规范在Slack频道上自动宣布该库的新版本我们通过结合使用自定义脚本，Fastlane工具和Travis CI来实现这一目标。在此过程中，几乎没有引入任何更改来帮助自动部署iOS-SDK。 iOS开发人员必须在每个.podspec文件中维护Changelog.md文件以获取发行说明和凹凸版本，以便部署脚本将读取此信息以实现发行自动化。我们可以从.podspec文件中读取版本，并使用Fastlane在Github上创建一个自动标记。 $ […]

使用iOS项目从Jenkins Jobs提取测试结果: 文件，文件，文件。文档是大型项目中的工件，以确保符合软件开发生命周期（SDLC）。实际上，所需的文件之一就是单元测试报告。在这里，我将带您进行2分钟的简短导览，以设置您的詹金（Jenkin）工作，以便生成测试结果报告。如果您不知道如何为您的项目设置詹金斯工作，则可以在这里查看我的上一篇文章。我们将使用Jenkins的插件调用Test Results Analyzer。这给了我们4种漂亮的测试结果可视化效果：表线馅饼酒吧转到->配置。转到构建后操作。选择添加构建后操作->发布JUnit测试结果报告。输入test-reports / *。xml并忽略其余字段。（包括红色消息）现在，触发一个构建以运行该作业，等待它执行所有测试用例，现在您可以从根文件夹中检索.xml文件。您还将在作业的主页上看到一个新图像。轻按一下“ 测试结果分析器”即可立即显示可视化效果！虽然这可能不是我们可以生成的最理想的测试结果报告，但是它为我们提供了足够的基本信息，可以为利益相关者提供简要概述执行哪种测试用例的情况（假设我们已经以TDD和BDD方式很好地命名了测试用例））。

使用Codesigndoc自动执行iOS代码签名以进行实际设备UI测试: 为了在真实设备上进行iOS UI测试，您需要安排代码签名。我们已经更新了Codesigndoc，现在它可以为您找到UITest目标的正确文件。用于在真实设备上运行应用程序首先，基础知识：我们非常确定您知道，如果您想在真实设备上运行您的应用，则需要先对其进行签名。为此，您将需要一个可爱的代码签名对，即Certificate和Provisioning Profile 。因此，您需要找到正确的证书和供应配置文件对，并将其上载到Bitrise。有时就像大海捞针（或两个）一样，这就是我们创建Codesigndoc工具的原因，该工具可以为您的项目导出所需的证书和配置文件。只需在项目的目录中运行此脚本： bash -l -c “$(curl -sfL https://raw.githubusercontent.com/bitrise-tools/codesigndoc/master/_scripts/install_wrap-xcode.sh)” 这将安装并运行codesigndoc工具。它将导出部署您的应用程序所需的所有代码签名文件：此后，您必须将导出的证书和配置文件上载到Bitrise。（转到您应用的“协同设计”标签。）好的，您现在可以通过Bitrise为测试人员部署应用程序并到App Store。但是，也可以在真实设备上运行UI测试，不是吗？用于在真实设备上运行UI测试好吧，在Bitrise上，您可以选择在Firebase的真实设备上运行UI测试。（了解有关在Bitrise上进行iOS设备测试的更多信息）。但这也需要在Bitrise上为UI测试目标提供另一对证书和配置文件对 … 要在真实设备上运行UI测试，需要使用其他配置文件。首先是基础知识： UI测试目标作为不同的应用程序在物理设备上的不同进程上运行。这意味着将需要像您的应用程序一样对其进行签名。您仍然还需要对您的应用程序进行签名（因为您的应用程序也将安装在设备上。）对于UI测试，您还将需要App和UI测试目标的代码签名文件。因此，您将需要同时运行install_wrap-xcode.sh （上面的脚本）和install_wrap-xcode-uitests.sh （下面的脚本）。幸运的是，Codesigndoc现在还具有导出这些代码签名文件的选项。只需在您的项目目录中运行此脚本即可。 bash -l -c “$(curl -sfL https://raw.githubusercontent.com/bitrise-tools/codesigndoc/master/_scripts/install_wrap-xcode-uitests.sh)” 它将导出UI测试目标所需的所有代码签名文件。在也上传了这些导出的证书和配置文件之后，就完成了。故障排除如果UITest扫描程序找不到所需的方案，请按照下列步骤操作： 1.确保您的方案对运行UITest有效。 […]

在Bitrise（beta）上推出适用于iOS的坚固，灵活的真实设备测试: 借助Google Firebase，也可以在iOS应用程序的Bitrise上获得以日志，视频和屏幕截图形式呈现的最终测试结果。一年前，我们推出了针对Android的真实设备测试，您很喜欢它，因此现在也可以在iOS上尝试它。 🎉 好消息是，除了您的Android应用程序之外，您现在还可以在各种设备和设备配置上测试您的iOS应用程序，并在Bitrise上查看生成的日志，视频和屏幕截图。测试实验室使用运行在Google数据中心中的实际生产设备来测试您的应用。测试实验室在iOS应用上运行XCTest测试。启用项目后，您需要添加和配置两个新步骤：请注意，这两个步骤目前都处于BETA阶段。请继续阅读以获取详细指南。 🤖 您必须分别为每个应用程序激活它。在 Certificate and profile installer 步骤之后，添加 [BETA] Xcode Build for testing for iOS 步骤该步骤的project_path输入设置为BITRISE_PROJECT_PATH env var，如果我们的扫描程序为您的项目生成了基本配置，则该BITRISE_PROJECT_PATH将指向您的Xcode项目或工作区。 scheme输入设置为BITRISE_SCHEME ，它也由扫描程序设置。确保您的默认方案具有最合适的目标（如果不使用包含某些方案的其他方案）。默认情况下，该步骤将使用Debug配置构建测试，并使用configuration输入根据需要进行更改。默认情况下，该步骤将为设备目标构建步骤，该步骤的destination输入设置为： generic/platform=iOS 。在 [BETA] Xcode Build for testing for iOS 之后添加 [BETA] iOS Device Testing 步骤 [BETA] Xcode […]

自动化的移动发行: 在Compass，移动团队高度依赖自动化。我们使用的工具包括： CircleCI 持续集成和交付对CircleCI的现代持续集成和交付平台充满信心地快速发布代码。提供于… circleci.com 我们喜欢CircleCI，因为它可以正常工作。仅需3行即可使其正常工作快车道 fastlane –用于持续交付的iOS和Android自动化 fastlane是发布您的iOS和Android应用程序的工具🚀它可以处理所有繁琐的任务，例如生成屏幕截图… fastlane.tools 我们喜欢fastlane，因为它可以让我们快速编写自动化脚本来编写新的appstore / testflight / hockey 曲棍球SDK HockeyApp –您的应用程序的平台 HockeyApp是收集实时崩溃报告，从用户那里获得反馈，分发测试版以及……的最佳方法。www.hockeyapp.net 我们喜欢曲棍球，因为它很容易上手：

使用Jenkins，Fastlane和TestFlight在iOS中进行持续集成和持续交付—第1部分: 每个开发环境都有自己独特的方式。它是分支策略，源代码控制系统，代码审查过程，合并和发布策略。本文的目的是显示实现CICD管道所需的基本步骤，作为快速参考指南。这更像是要点。您还可以参考下面提供的链接，以详细了解这些步骤。使用的工具是Xcode，GIT，Jenkins，Fastlane和TestFlight。安装Xcode及其命令行工具。从https://brew.sh/安装HomeBrew软件包管理器 / usr / bin / ruby -e“ $（curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install）” 3.用ruby稳定安装RVM： \ curl -sSL https://get.rvm.io | bash -s稳定—红宝石 4.安装Java8，因为Jenkins使用Brew在Java8上运行。酿造自来水桶/版本 brew cask安装java8 如有任何问题，您可以直接从Oracle网站下载并安装Java8。 5.使用Brew安装Jenkins。酿造安装詹金斯 6.启动詹金斯酿造服务开始詹金斯 7.在浏览器（http：// localhost：8080）中打开Jenkins，登录，创建一个用户。如果看到“解锁詹金斯”屏幕，请按照提供的说明进行操作。 8.配置Jenkins后，从“管理Jenkins”->“管理插件”安装“ Xcode集成”。 9.完成后，通过单击“创建新作业”来创建新作业。如果您已经在另一台机器上准备好了作业，则只需复制“ jobs”文件夹，然后将其粘贴到/user/.jenkins下的目标机器中即可。在我们进行更多工作时，最好查看系统中所有隐藏的文件。这是执行此操作的参考。 10.创建作业后，将其配置为与源代码控制存储库连接。 11.安装Fastlane 酿造桶安装fastlane 12.如果您还没有“ bash_profile”，请创建一个新的。您可以参考此操作。 13.在代码库中初始化Fastlane。编写动作。将更改提交到存储库。这是示例的Github参考。 […]

Travis Stages的iOS部署管道: 持续集成的过程执行各种活动，例如分析，构建，测试和部署iOS应用。将每个构建任务分解成各个阶段并独立执行它们是一个好主意。此过程也称为构建管道或部署管道。作为iOS开发人员，您可能已经体验到构建iOS应用可能需要很多时间才能进行测试。管道是处理iOS开发的各个阶段以获得快速反馈的方式。在花费了数小时的构建和测试阶段之后，我们可能不想因代码样式问题而导致构建失败。自托管的持续集成服务器（如Jenkins和TeamCity）具有创建构建管道的良好支持，但是基于云的CI服务器（如TravisCI，CircleCI等）也正在推出部署流水线功能。在这篇文章中，我们将看到如何使用Travis Stages功能设置iOS部署管道。请注意，我以TravisCI为例，因为我将其用于一些开源项目。其他可能基于CI的CI服务器也可能具有类似的功能。 iOS部署阶段在进入TravisCI设置之前，我们将了解部署任何iOS应用的重要阶段是什么。主要的构建阶段是分析源代码中的代码样式问题使用XCTest或其他框架进行测试构建和存档iOS应用将iOS应用分发到其他Beta测试服务将iOS应用上传到iTunes Connect 这些是必须在连续集成服务器上自动化的主要阶段，才能实现自动部署。特拉维斯舞台万一TravisCI刚开始使用，它是一个嵌入Github的基于云的持续集成平台，该平台允许为开源以及企业项目运行CI构建。它具有良好的文档，可帮助您开始进行持续集成。 TravisCI宣布了Travis Stages的新功能，以实现针对开源项目和企业项目的部署管道。可以通过在.travis.yml文件中添加以下代码示例来启用这些阶段工作：包括： -阶段：测试脚本：./ test 1 -＃阶段名称不是必需的，将继续使用`test` 脚本：./ test 2 -阶段：部署脚本：./ deploy 为了在iOS项目中应用此原理，让我们在GitHub上创建一个开源项目，如下所示（您可以使用任何iOS应用）在Xcode中创建名为SwiftLint-CI的空白单视图应用，其中包含单元和UI测试目标使用CocoaPods添加SwiftLint来检查Swift代码语法。这可以通过创建Podfile并运行pod install命令来完成。现在，我们已经为CI配置了一个基本的iOS项目。现在，我们可以添加支持以在TravisCI上运行构建并启用以下阶段。使用SwiftLint为Lint Swift代码构建阶段构建阶段以运行单元测试构建阶段以运行UI测试使用阶段创建.travis.yml TravisCI使用macOS虚拟映像来运行构建，所有映像的列表都可以在此处找到。我们可以选择最新的xcode9图像来运行演示应用程序的构建。 […]

agvtool：自动化iOS内部版本号和版本号: DevOps和持续交付实践可将持续构建部署到我们的内部或Beta测试平台。必须管理iOS应用的版本和内部版本号。作为最佳DevOps做法，iOS团队应经常向AppStore发布新版本（即市场营销版本），并且应在向AppStore提交应用程序之前为每个版本进行多次构建。该发行版可能具有具有不同功能的不同内部版本。管理iOS应用的内部版本号和版本号非常重要，以确保我们将正确的内部版本发送到AppStore。在本文中，我们将看到如何使用agvtool命令行实用程序来管理我们的iOS应用的版本和内部版本号。版本和内部版本号在开始使用agvtool之前，让我们了解什么是iOS应用程序的版本和内部版本号。版本号基本上，版本号是该应用程序的市场编号，它是显示给应用程序用户的编号，用于标识应用程序的发行版本。它作为CFBundleShortVersionString（捆绑版本字符串，简称）存储在应用程序的Info.plist中。内部编号内部版本号标识应用程序的未发布或已发布版本。它作为CFBundleVersion（捆绑版）存储在应用程序的Info.plist中。我们可以为特定版本进行多个构建。 agvtool agvtool是一个命令行工具，可让您自动将这些数字递增到下一个最高数字或特定数字。该工具与Xcode命令行工具一起提供，可以从xcrun实用程序直接访问。 $ xcrun agvtool $ xcrun-查找agvtool 您可以从其文档页面阅读该工具提供的选项 $ man agvtool 这将显示agvtool随附的所有命令。现在，我们将看到如何在真实的iOS应用程序上使用agvtool。为了做到这一点，让我们在Xcode中创建一个名为agvtool-Demo的单视图iOS应用。从命令行开始使用agvtool之前，需要确保以下几点。启用agvtool和版本控制系统禁用/启用源代码管理设置我们将看到如何在Xcode中进行设置启用agvtool 为了启用agvtool，我们需要确保在目标构建设置中正确设置了“ 当前项目版本”和“ 版本控制系统”属性。选择目标构建设置，然后搜索“版本”。现在将“ 当前项目版本 ”设置为1，并将“ 版本控制系统”值选择为“ Apple Generic” 接下来要验证的是确保“ 信息”选项卡具有捆绑软件版本和捆绑软件版本字符串，对于新项目，简短值可能设置为1。禁用/启用源代码控制（CVS，SVN）当agvtool更改版本或内部版本号时，它将在Xcode项目内的某些文件中进行更改。如果使用CVS或SVN，则可以将这些更改提交给源代码管理。如果您不使用SVN或CVS，则无需担心这些设置。默认情况下，提交对CVS或SVN的更改为ON，但是，我们可以通过运行以下命令来禁用该设置。 $默认写入agvtool SVNEnabled否 $默认写入agvtool […]

从头开始创建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中来实现此目的。 […]

缓存迦太基以加速iOS持续集成: 几乎没有任何iOS项目没有任何依赖关系。几乎每个项目都必须管理内部或第三方的某种依赖性。每种主要的编程语言都有自己的依赖性管理系统。 Swift具有多种选项来管理依赖项。苹果很久以来一直在开发自己的Swift Package Manager。认真地讲，很久以来，iOS开发人员都渴望获得Apple支持的官方依赖项管理器，但事情似乎以乌龟的速度发展着。 Swift Package Manager仍然不支持iOS项目。 CocoaPods是iOS项目中最常用和最传统的依赖管理，因为开发人员没有其他选择。 CocoaPods是一种神奇的，不可思议的，超能力的魔咒，它使您的Xcode项目无法正常工作。它建立依赖关系，创建工作区，执行一些脚本和其他东西。 CocoaPods运行良好，但是很少有开发人员了解运行pod install命令时发生的实际情况。如果一切正常，每个人都会感到高兴，但是当pod安装失败时，每个人都会感到恐慌。没有人知道如何解决该问题，需要花费数小时，数天或数周的时间才能解决由CocoaPods造成的混乱。爱它还是恨它，无论哪种方式，您都必须使用它。迦太基的诞生 Somone了解了iOS开发人员对CoacoPods的痛苦，并制作了一个名为Carthage的婴儿作为CocoaPods的替代品。 Carthage仅适用于动态框架，并且使开发人员能够完全控制他们对Xcode项目所做的工作。它只是构建框架，开发人员必须手动将那些框架链接到目标的各个构建阶段。迦太基运作良好，但缺点不多迦太基仅适用于动态框架迦太基的开发者社区很小，为该项目做出了贡献使用迦太基时涉及的手动步骤很少主要缺点是，它是如此缓慢，特别是在CI服务器上。迦太基检出和构建每个构建的每个框架。对于CI而言，这绝对不是一个很好的方法，因为构建速度将非常缓慢且冗长。如果没有任何更改，则没有干净的解决方案来缓存Carthage /目录。在这篇文章中，我们将看到如何在CI服务器上缓存Carthage目录并加快构建速度。 CI上的迦太基迦太基最常见的用法是运行迦太基更新或脚本作为CI脚本的一部分，该脚本会修改所有依赖项以使用最新版本的Cartfile.lock文件更改，该更改不正确，并导致签出和构建所有依赖项。这将使CI的构建速度非常慢。因此在CI上使用迦太基的理想方法是检查Cartfile.lock是否存在。如果该文件不存在，那么我们必须使用Carthage bootstrap引导所有依赖项。如果Cartfile.lock存在但未更改，则无需执行引导程序或更新操作，并且可以使用先前版本中Carthage目录中的内容。如果存在Cartfile.lock并更改了某些依赖关系，则我们仅需引导那些过时的依赖关系，而不是全部。现在，我们知道了如何使用Cartfile.lock状态执行引导或跳过引导的机制。下一步将是编写一个脚本来做到这一点。根据CI服务器提供的环境变量，我们可以通过多种方式实现这一目标。 Jenkins使用的脚本如下所示 [-f Cartfile.resolved]; 然后 CARTFILE_CHANGED =`git diff –stat $（GIT_PREVIOUS_SUCCESSFUL_COMMIT）$（GIT_COMMIT）| grep’\ […]