Tag: 持续集成

启用代码覆盖以迅速进行Bamboo: 在我工作的地方，我们将Bamboo作为我们的iOS开发CI工具。 Bamboo的一个不错的功能之一是它与Clover集成在一起，并且将显示详细的覆盖率和单元测试数据。缺点是这些功能最容易与Java集成。好处是，只需做一些工作，我们就可以为iOS和Swift做类似的事情。必备工具您需要在构建服务器上使用以下工具 Python /点 cobertura-clover-transform（https://github.com/cwacek/cobertura-clover-transform） xcov（https://github.com/nakiostudio/xcov）[ 可选 ] slather（https://github.com/SlatherOrg/slather）扫描（https://github.com/fastlane/fastlane）步骤1：设定Python 在您的Bamboo构建服务器（或专用的Mac构建节点）上，创建python虚拟环境并安装cobertura-clover-transform pip安装virtualenv cd〜/开发虚拟环境来源venv / bin / activate pip安装cobertura-clover-transform 这将创建一个安装了cobertura-clover-transform工具的虚拟环境-该工具将覆盖率报告转换为Bamboo可以读取的三叶草格式步骤2：在Bamboo上安装其他工具下一步是安装所需的红宝石宝石： sudo gem install xcov fastlane slather 步骤3：配置本地项目以进行代码覆盖您的XCode项目需要配置为收集coverage数据。您只需要执行一次此步骤，然后提交更改。 slather设置步骤4：配置Bamboo 在Bamboo中，您将需要添加一个新的脚本任务，该任务将运行生成覆盖率和单元测试结果所需的命令。示例脚本代码：扫瞄第一步是运行单元测试以生成coverage数据。这是通过扫描完成的扫描-配置调试\ –scheme \ –output_types junit，html \ –output_directory xml_report / mv xml_report […]

如何将Bitrise构建与多个Danger文件并行化: 我最近正在为我们的iOS移动应用程序并行化Bitrise构建以减少其构建时间，该时间从〜21分钟减少到不到13分钟。我工作的主要目标是分离工作流，以减少Bitrise上的构建时间。在分离出工作流之后，我还希望我们的机器人将每个工作流的Danger结果发布到GitHub上，以便我可以分别获得每个人的反馈。以下步骤基于我的工作，分离了工作流程，向这些工作流程添加了两个不同的Danger文件，并让我们的漫游器发布了两个单独的消息。如果您的团队规模较小（或有更多的并发运行），那么这些时间甚至有可能减少。在我们的案例中，一个可能的想法是将SwiftLint分离出来。步骤1：并行工作流程您可以使用Bitrise Start Build使一个工作流程触发另一工作流程。可以将其添加为工作流程的第一步。在输入变量中，您需要声明一个Bitrise访问令牌和要触发的工作流程。在工作流程的最后，添加“ Bitrise Wait for Build步骤。如果您不等待第二个工作流程，即使第二个工作流程失败，GitHub上的Bitrise状态也可能被标记为通过。步骤2：运行单独的Dangerfile 每个工作流程都可以运行一个单独的Dangerfile。我的第一个Dangerfile（我称为DangerStep01）位于~/MyApp/Danger/ 。将Script步骤添加到您的工作流程并指定脚本内容。只需添加–dangerfile=Danger/DangerStep01即可指定文件的位置及其名称。对每个步骤重复一次。我选择在第二个构建可能完成之前运行Dangerfile，以便我可以立即获得工作流程1的反馈。第3步：让您的GitHub机器人帖子两次您还可以通过添加一个id使您的机器人为每个Dangerfile分别发布两次不同的时间。这样做的好处是，您的机器人只会在每个Dangerfile上发布一次，并在您触发新的构建时更新这些单独的发布，从而避免了它向您的提取请求发送垃圾邮件。要添加ID，您必须在bundle exec danger –danger-id=appBuild的末尾添加–danger-id=appBuild 。您可以选择所需的任何ID，它最终将显示在GitHub上。我叫我的appBuild和appTests 。而已！

用Bamboo加快迦太基的建造: 迦太基是一个出色的依赖项管理器，但是，当项目变得复杂时，构建时间可能会受到影响，尤其是在诸如CI之类的CI环境中。本文详细介绍了我为缓解这些问题而开发的工作流程。步骤1：配置链接的存储库在我们的构建环境中，我们使用两组链接的存储库-一组专门用于迦太基，而另一组用于常规代码更改。仅当检测到对Cartfile或Cartfile.resolved的更改时，工件特定的配置才会“运行”。含义是要么更新了现有的依赖关系，要么添加了新的依赖关系。在我们的构建配置中，我们使用Fastlane，它会在进行更改时自动添加标签“ fastlane的构建版本碰撞…”，我们特别将其添加到排除变更集，这样我们就不会以循环构建循环结束。如果您不使用Fastlane，则不需要此行。对于主存储库，我们将仅包含匹配的更改切换为排除与以下模式匹配的所有更改。这意味着，如果提交修改了Cartfile ，它将不会触发构建。步骤2：计划设定对于我们正在开发的每个ios应用程序，我们使用2个计划：一个应用程序-工件计划和一个应用程序构建计划。实际上，我们还有其他计划来处理不同的分支和部署，但这超出了本文的范围。构建计划：应用程序-工件 Artifacts计划负责运行Carthage并生成所需的项目依赖项。我们发现此步骤运行起来很慢，而且不需要经常发生。要配置此计划，您需要确保将其指向步骤1中配置的Artifacts存储库。如下配置计划：它具有一个单阶段和一个带有两个任务的作业：源代码签出和一个运行以下命令的脚本：迦太基引导程序—平台ios —无用二进制文件然后确保定义一个共享工件，例如：运行carthage bootstrap时，它将依赖项下载到Carthage / Checkout文件夹中，然后将框架构建到Carthage / Build文件夹中。因为我们只需要框架而不是源，所以我们仅在工件中包含Carthage / Build目录建设计划：申请该计划链接到在步骤1中配置的主存储库，负责日常构建应用程序。除非您更改Cartfile中的内容，否则此计划将在每次推送的提交上运行。在配置计划时-添加工件下载任务并选择上面定义的共享工件。这将使用Carthage / Build文件夹填充您的构建目录，该文件夹将具有构建所需的所有正确动态框架。关于如何配置适合您的构建任务-无论您使用Fastlane，xcodebuild还是xctool。如果您使用Fastlane，请确保没有在Fastfile中调用迦太基任务，否则将重复所有迦太基工作。触发建筑最后一步是返回到“ Application-Artifacts”构建计划，并编辑“ Dependencies”选项卡，并确保该计划将在每次构建时触发“ Application”构建计划。这样，如果更新了Cartfile，它将自动使用更新后的依赖项重新构建主应用程序。摘要在我们的环境中，我们发现在实施此构建方案之前需要花费多达40分钟的构建时间。 […]

播客访谈：在Apple Bubble中自动化iOS应用: 原始博客文章： http : //shashikantjagtap.net/podcast-interview-automating-ios-apps-in-the-apple-bubble/ 最近，我接受了Joe Colantonio的播客采访，主题为“在Apple Bubble中自动化iOS应用程序”，讨论了iOS测试自动化和iOS DevOps空间的当前趋势。 Joe运行了TestTalks播客，所有有关测试自动化最佳实践的内容，到目前为止，他有199集。他已经采访了许多行业专家，我很高兴也有机会与他进行了采访，分享了我在iOS自动化和DevOps方面的经验。我的采访是TestTalks播客系列的第199集。在iTunes上可以找到它，也可以在TestTalks网站上找到播客片段的详细信息。在此播客采访中，我们涉及了iOS测试自动化和DevOps的各个主题，包括这些天公司如何测试iOS应用程序？如何为iOS测试自动化XCUITest Vs Appium选择工具？ iOS中有哪些“行为驱动开发”选项？如何使iOS Tests CI或DevOps友好？如何在iOS应用程序中测试REST API？ AI / ML可以测试iOS应用程序吗？如果您要使用iOS Automation或iOS DevOps，则一定要查看此剧集。在手机上喜欢的播客客户端中搜索“ TestTalks”第199集。希望您会发现此情节有用。让我知道你的想法？我在Twitter @ Shashikant86 像XCBlog的 XCTEQ 发布的帖子一样？您可能还喜欢我们的一些服务，例如访客博客或Mobile DevOps（CI / CD）或测试自动化。在 Github 上搜索我们的服务，开源项目，或者在 Twitter ， […]

iOS应用程序持续交付的力量: 可以说，要使团队超越一个人，最具挑战性的方面之一就是确保每个人都拥有相同的环境。不仅所有团队成员都需要了解项目的高层计划和目标-有效共享正在进行的功能和里程碑的确切状态对于团队协作至关重要，这确实至关重要。从设计到实施举例来说，假设设计师一直在为应用程序开发新屏幕，并且团队已决定是时候开始在代码中实现该新屏幕了。设计师将他们的设计及其所有资产交给开发人员，然后他们开始在Xcode中构建新屏幕。由于估计需要一到两周的时间，因此设计师将继续执行下一个任务，具体取决于公司的规模，这可能需要与全新的开发人员，产品经理，测试人员和其他设计师合作。但是，这种交接几乎从来不是一个干净的中断。交付给开发人员的设计很可能无法回答他们所有的问题，而且某些细节常常会在翻译过程中“丢失” -不是由于能力不足，而是因为我们尚未建立共享关系上下文。我们理想的情况是，设计师/开发人员的交接实际上根本不是交接，而只是连续反馈循环中的又一步。如果我们能够在完成设计工作之前获得设计人员对设计实现的反馈，那么我们更有可能对这些反馈采取行动，并且在我们解决问题之前要正确无误。无论如何都要运送我们已经建造的东西。一遍又一遍地讲， “我们将在下一版本中对其进行修复”可能是一件令人沮丧的事情。持续集成在iOS开发者社区中，我们早已意识到持续反馈的价值-通过持续集成的日益普及。使用像Bitrise这样的服务，我们可以通过为所有受支持的设备构建应用程序并在结果上运行我们的自动化测试套件，lint和其他工具，来快速获取有关推送到远程存储库的任何代码更改的反馈。最重要的是，使用诸如GitHub Pull Requests之类的方法添加同行评审，我们已经建立了持续的反馈循环-在其中，作为一个持续的过程，代码被编写，审查，测试并集成到主要代码库中。这不仅使我们的工作流程更流畅，而且还为错误提供了安全网。错误甚至可以在合并之前就被捕获，可以解决和重新测试版本控制冲突，并且可以调整体系结构不一致之处。可以说，一旦您完成了使用持续集成的项目，就很难在没有项目的情况下恢复工作。那么，我们如何才能扩展持续集成模型，使其不仅成为开发人员的工作流，而且使我们团队的其他成员（例如设计师，产品经理或外部利益相关者）参与其中？输入连续交付。持续交付如果绿色的构建和通过测试的套件不是我们持续集成过程的终点，又该如何将每个构建实际交付给我们的团队怎么办？这样，我们不仅可以使开发人员，而且可以使我们团队中的每个人都进入我们的反馈循环。设计师可以看到其实施设计的确切状态，产品经理可以制定更准确的计划，而外部利益相关者（例如代理商或自由职业者的客户）可以随时透明地看到其项目的确切状态。虽然连续交付已成为Web和后端开发之类的越来越普遍的做法，但在iOS上却有些棘手-因为我们无法真正将所做的每项更改都部署到App Store或什至实际上是TestFlight （取决于更改的数量）。值得庆幸的是，Bitrise可以解决此问题。通过将Xcode Archive & Export for iOS的Xcode Archive & Export for iOS步骤添加到Bitrise工作流程，新的IPA（app）工件将被存档并保存到每个版本中。将该步骤链接到Deploy to Bitrise.io步骤将依次获取该IPA文件并将其部署到Bitrise的内部测试服务。完成后，您在Bitrise上邀请加入该应用程序的每个人都可以访问这些版本。代码签名难题的最后一步是确保已部署的应用程序以能够在所有团队成员的设备上运行的方式进行代码签名。为此，有四个主要选项：如果您的公司拥有Apple 颁发的企业证书 […]

SonarQube“托管在您的服务器上” + Travis CI + Swift: 我在本地计算机上安装了SonarQube并成功运行，但目的是将其与Travis CI集成。要将SonarQube与Travis集成，我有2种选择：使用SonarCloud。（文档位于https://docs.travis-ci.com/user/sonarcloud）使用我的服务器上托管的Sonar。选择第二个选项-我总是更喜欢服务器上托管的服务。从SonarSource购买了Developer Edition，网址为https://www.sonarsource.com/plans-and-pricing/developer/ 为什么要使用开发人员版？？答：我想要Swift语言支持。您可以在网络上找到足够的文档来将SonarCloud与Travis CI集成，但是要将其与托管在您自己的服务器上的SonarQube集成并不是一件容易的事。这就是为什么我想到写这篇文章的原因 .travis.yml设置我假设您已经知道如何使用您的Github帐户设置Travis。接下来，您需要告诉Travis如何使用SonarQube对代码进行质量检查。 .travis.yml中的以下代码段将帮助您实现这一目标：插件： sonarqube：truescript： -声纳扫描仪-D sonar.host.url = $ SONAR_HOST_URL -D sonar.login = $ SONAR_TOKEN -Xenv：全球： —安全：SecuredSonarToken-SONAR_HOST_URL = SonarHostURL 要生成SonarHostURL的SONAR_TOKEN登录，请转至我的帐户->安全->生成安全令牌。将生成一个令牌，使用travis encrypt SONAR_TOKEN=token —- add此令牌travis encrypt SONAR_TOKEN=token —- add sonar.projectKey = projectKey sonar.projectName =项目名称＃数字版本（可以在plist中自动找到，只需注释此行） sonar.projectVersion = 1.0 […]

与Jenkins和Fastlane的持续集成和持续交付: 测试一直是大多数大中型项目的重要组成部分，因此，对我们的主分支进行的每次代码更改都必须触发测试套件的完全执行，这一点很重要，以确保我们所做的更改不会破坏其他任何代码测试用例。这就是我们所说的持续集成（CI）。这是为了验证代码更改的正确性并快速识别集成错误。在收到CI的同意后，下一步是确保交付包含新功能和/或错误修复的新软件。这就是我们所谓的持续交付。由于CI已解决了测试套件的问题，因此我们在此处运行脚本以对证书进行签名（在Xcode / iOS上下文中），并使用第三方工具（如FastLane）执行存档，以触发可发送到用户电子邮件的可部署软件。立即进行测试。詹金斯是什么？詹金斯（Jenkins）为我们提供了无缝方式，以使用管道为几乎任何组合的代码语言和源代码存储库设置CI / CD环境。它是一个开源自动化服务器，可用于自动化与构建，测试以及交付或部署软件有关的任务。它也是帮助DevOps团队的必不可少的工具，由于我们在特定时期内管理的项目数量不断增加，以确保其高质量的交付成果， DevOps团队如今越来越受欢迎。 Jenkins的插件可与Github和BitBucket等第三方源控制器集成。什么是Fastlane？ FastLane是用Ruby编写的CD工具，用于发布移动应用程序（iOS / Android），为您消除了繁琐的任务。由于其针对iOS生态系统的较早开发，我们可以看到iOS提供了比Android更多的功能。注意：如果您是Fastlance的新手，也可以查看我们的Fastlane教程。先决条件为了完成本教程，我假设您已具备以下知识和工具：有关构建iOS项目的一些基本知识。 Swift中一些具有Quick＆Nimble的单元测试知识。一些虚拟主机知识。使用本教程的Mac机器。用于生成证书的开发者帐户。忍耐设置整个过程非常耗时且乏味。通过大量的试验和错误，我可以将所有内容拼凑在一起，以创建本教程。在撰写本文时，可能会有更新进入，内容可能已过时。请比较出现的版本升级并进行相应处理。不要犹豫，给我留言，这样我就可以相信您并更新本教程，以使其余人员受益！谢谢☺ 你会学到什么？通过阅读本教程，您将学到很多有关CD和CI的知识，包括：如何设置Jenkins 2.121.3（Java 8）。如何设置Fastlane 。如何使用Jenkins + Github管理您的CI 。如何使用Jenkins + Github + Fastlane管理CD […]

使用使用Cocoapods的iOS项目设置GitLab CI: 我们都为应用程序编写测试，并将其保留在版本控制的系统（如GitLab或GitHub）中。但是，我们如何配置GitLab为我们运行单元和UI测试？我找不到很多文档来解释如何在GitLab上为iOS设置持续集成，因此我正在写这篇文章。 Victor Peschenkov在他的文章中解释了如何在Fastlane中使用GitLab CI。我的文章重点介绍如何自己运行所有内容。要求为了为iOS设置GitLab Runner，我们需要以下工具：苹果电脑 Xcode 10 GitLab.com帐户（或一个自托管帐户）家酿 CocoaPods（使用自制软件： brew install cocoapods ）请先安装这些工具，然后再继续。配置Xcode 确保从Mac App Store下载Xcode。安装完成后，打开它并创建一个项目以确保它已完全安装并正在运行。 iOS专案我创建了一个示例项目，以帮助您更快地入门。随意分叉它或使用您自己的项目。请使用以下方法验证您的安装： git checkout git@gitlab.com:skofgar/ios-ci-sample.git 切换到项目文件夹并运行pod install 在计算机上运行以下命令，以验证您可以成功构建并运行测试-这意味着没有“失败”或其他错误消息 xcodebuild测试 -workspace“ CI Sample.xcworkspace” \ -方案“ CI示例”-目标“平台= iOS模拟器，名称= iPhone XR，OS = 12.0” \ | xcpretty -s 安装GitLab Runner iOS项目需要特殊的GitLab […]

大规模自动化移动交付: Fastlane最佳做法我大规模使用Fastlane的旅程始于为一个团队开发的iOS应用程序构建全自动连续交付系统。这发展成两个移动应用程序：一个由多个团队开发的Android应用程序和一个iOS应用程序。当然，这些团队采用了不同的工具集，各种测试环境以及不同的应用程序配置。带着我的羽毛，我被要求在两个平台上的许多应用程序中执行相同的操作，这些应用程序具有许多开发团队，许多环境和许多外部资源。我有提到“很多”吗？要使数十个团队的数百名开发人员的工作自动化，从而为数十种移动应用程序做出贡献，是很困难的。团队具有不同的开发方法，架构，工具，发布节奏和门控要求。要实现这些折衷的交付目标，就需要删除手动流程，提高自动化可靠性，并使团队能够灵活地定义和支持各种流程。首先，让我们奠定Fastlane基础，然后深入研究解决许多不同目标的实施细节。您可以在GitHub上找到完整的代码示例集。访问 Scaling iOS CI / CD的4课，了解此过程的其他方面，包括构建可伸缩的iOS 执行环境以及我们在此过程中面临的三个挑战（环境不一致，容量有限和CI / CD不够灵活）。 Fastlane 101 —基础知识 Fastlane是一个非常活跃的开源项目，使用Ruby实现，目前由Google赞助。项目维护者可以迅速响应社区提出的问题，并热烈欢迎外界的贡献。 Fastlane作为统一框架，可为iOS和Android应用程序定义自动化流程。它甚至可以更好地将流程定义与使用这些流程的项目一起移入版本控制中。 “ Fastlane是为您的iOS和Android应用自动执行Beta部署和发布的最简单方法。 🚀它可以处理所有繁琐的任务，例如生成屏幕截图，处理代码签名以及发布您的应用程序。” — Fastlane文档 Fastlane术语项目：利用Fastlane的代码库。 Fastfile ：包含使用Fastlane特定于域的语言（DSL）进行项目编码的文件。 action ：在Fastfile（文档）中使用的单个可配置操作。车道：构成一个过程的动作的集合。通道可以调用其他通道。 private_lane ：只能由其他通道调用的通道，不能直接在命令行（文档）上调用。 function ：一个封装逻辑的Ruby函数，可以在单个Fastfile中重用而无需更改通道。 plugin ：一个Ruby宝石，封装了其他现成的未提供的动作。开发期间：构建：使用调试构建设置二进制 […]

Xcode和CI中的秘密变量可带来乐趣和收益💌: 让我们以一个小小的事实作为本文的开头：您的代码存储库中永远不应包含任何敏感信息。没有例外。 API密钥，密码，您的电子邮件（包括集成测试之类的内容）。这确实是不好的做法，但几乎每个人都这样做。甚至我上班的回购中仍然有电子邮件或其他内容。这个问题非常普遍，GitHub上有官方指南可以从存储库中删除敏感信息。 GitHub上还有300k +提交仅删除密码（这是无效的，但\\（（））_ /¯）。这个问题如此猖,，有许多著名的开源项目致力于解决这个问题。既然我们已经概述了问题，那么我们需要设计一个既安全又容易的解决方案。我认为让“错事难”和“正确事”变得简单同样重要。这将使开发人员（也就是您和我👋）将秘密密钥用于分析，库，集成测试等。所有这些都不会破坏我们的工作流程（我们仍然希望能够按⌘+ R / B / U，并使用现有的工作流程。）灵感事实证明，商业CI提供者已对此问题提供了不错的解决方案（💯为BuddyBuild上令人惊叹的人们提供了思考的💯🙌）大多数CI提供程序都有一种存储加密变量（buddybuild：和travis）的方法，这些变量是父进程环境变量的一部分。不过有两个问题：您如何在本地使用这些🤔？如何在Xcode中访问环境变量？为了弄清楚这一点，我查看了我的同事的设置（他们通常使用CLI而不是IDE进行工作）。他们的本地设置通常涉及一个名为`env-vars.sh`的bash脚本（位于他们的.gitignore中）。看起来像这样：太棒了现在，我们可以在构建阶段添加构建阶段（“运行脚本”）。注意，您需要在“编译源”步骤之前添加此代码。这是因为我们需要添加一个新的.swift文件来编译和获取我们的环境脚本（如果存在）并运行Sourcery。我们需要在项目中添加`.stencil`模板文件，并向Sourcery提供它的父目录，这样它才能发挥作用。这是脚本（用于⌘+ C’ing）：现在，运行一次⌘+ B，以生成源文件。（不用担心您的构建是否失败。这是因为我们尚未添加生成的文件）。它的扩展名为`.genic.swift`。将其添加到您的项目中，现在您将可以从源代码inside内部访问这些变量。 PS：请注意，您必须在.gitignore中添加`.generation.swift`，以便您的凭据不会意外地出现在您的仓库po中。现在，您可以无缝地，轻松地使用我们先前声明的`testCreds`结构，而不必担心CI或开发机🎉中的实现细节。并且您当前的工作流程不受影响（⌘+ R / B / U仍然有效🎊）感谢您阅读我的文章！如果您有任何疑问，请随时在Twitter上与我联系（大多数情况下我都是@codeOfRobin）或询问中型评论。 PPS：我将很快与Abheyraj Singh一起研究一些非常酷的东西。敬请关注！