Tag: 持续集成

在Bitrise app上应用程序的代码签名选项卡上查看所有文件信息: 您是否在Bitrise上看到自动执行“ iOS Auto Provision”步骤？我们确定您有。但是，如果您不想使用它，则可以在代码签名选项卡上喜欢我们的更新。有关配置文件和代码签名身份的更多信息，意味着更容易调试和更简单设置：您将看到需要上传哪些文件，到期日期和错误的密码。打开应用程序的工作流程编辑器，然后单击“代码签名”选项卡。以前，只有配置概要文件和代码签名身份的文件名在此可见，并且没有指出哪个概要文件与哪个身份匹配。但是时代在变。供应配置文件在更新的选项卡上，您将看到每个供应配置文件的ID，导出类型，团队名称和捆绑包ID 。到期日期也将列出，因此如果您需要更新您的配置文件将很清楚。单击配置文件后，您会在弹出窗口中看到更多信息（从文件的元数据中提取）。它将包括以下内容的列表：所有匹配的证书（不仅是上传的证书）设备的UDID 能力代码签名身份在代码签名身份下，您可以上传新的身份或找到以前上传的身份的列表。上载身份时，我们会自动检查您的密码是否正确，以便您可以立即排除可能的错误。（如果您不使用密码，那么我们也可以。）您可以拥有一个包含多个身份的.p12文件，并以此身份进行上传，也可以一个一个地上传。无论哪种方式，您都可以在身份名称的下方看到团队和有效期，或者对于绑定的ID，可以在弹出窗口中找到此信息。这将帮助您在Apple Developer Portal上及时重新生成它们。这仅仅是开始，我们也在开发其他一些很酷的功能：单击预配配置文件后，您不仅会看到所有匹配配置文件的列表，还会看到它们是否已经上传以及它们是否已过期。在同一弹出窗口的“设备”下，除了UDID外，您还可以确定该设备是否已经添加到Bitrise中以及由哪个用户添加。代码签名愉快！ ✍

使用Swift的iOS项目中的持续集成环境变量: 在今天的文章中，我们将讨论一个非常常见的问题，我们iOS开发人员有时必须在我们的开发工作流程中处理这个问题。问题是如何存储应用程序生产API密钥，以存储我们使用的服务，开发，测试或生产服务器URL以及其他可能过于敏感而无法通过代码添加到我们的存储库中的数据。以及如何分隔持续集成管道以使用不同的API密钥，访问密钥，服务API地址或任何敏感数据进行生产，测试或开发构建。有任何方法可以解决该问题。包括在这篇名为Xcode中的Secret变量和CI的惊人文章中描述的内容，以获取乐趣和收益由出色的Flawless App团队所带来的灵感之一，实际上是这个项目的灵感之一。这个小项目叫做Swift Variable Injector 。另外，当我进行研究时，有人问我相同的问题的另一个思路是这样做的。我们将在下面显示的示例方法与[1]中描述的方法非常相似，该方法使用Sourcery和代码生成基于环境变量值创建快速文件，并将其插入到Continuous Integration流水线中的项目中。现在，我们将演示一个示例，说明如何使用Swift变量注入器执行文字值替换，将环境变量值注入到Continuous Integration Pipeline中的Swift代码中。所以…… 开始吧首先，创建我们的项目，让我们定义用于处理环境变量和Continuous Integrations值的类。注意：这些Xcode环境变量参数在启动时而不是在编译时传递给Process（App）。这意味着您将使用这些参数启动该过程，仅当使用Xcode运行该项目时，您才具有这些值。通常仅对开发有用。如果您希望能够在不使用Xcode的情况下启动已部署的版本，则可以将CI类从var模式替换为键值。但是重要的是，在提交和推送它时，不要让它静态定义。 :)） CI.swift类声明在连续积分的变量注入器步骤中要替换的变量。注意：重要的是文字值与格式$（ENV_VAR_NAME）匹配。在持续集成方面，我们必须定义一个环境变量，并在每个工作流程（生产，测试等）中为其指定值。我将使用Bitrise服务在此处演示步骤。但是，大多数CI服务都提供了所需的所有功能。在这里，我们基本上为每个工作流程定义环境变量。因此，例如，如果我们有一个生产工作流程和一个Beta测试工作流程，则可以在两者上定义键，但要使用不同的值。在为每个工作流程定义变量或秘密之后。现在，我们可以在构建步骤之前添加变量注入步骤。您可以通过两种方式执行此操作：使用shell脚本您可以在构建之前定义一个步骤，以运行以下脚本来安装和运行变量注入器：＃安装 CURRENT_DIR =“ $ PWD” cd / tmp curl -OL https://github.com/LucianoPAlmeida/variable-injector/releases/download/0.2.1/x86_64-apple-macosx.zip 解压缩x86_64-apple-macosx.zip cp -f ./x86_64-apple-macosx/release/variable-injector / […]

使用Carthage在iOS上建立依赖关系: 在本文中，我想分享我使用Carthage构建依赖项的经验。首先，迦太基闪耀着简单。通过在Cartfile添加适当的行并运行carthage update ，开始在Xcode项目中使用某些外部依赖关系非常简单。但是众所周知，生活是残酷的，有时我们需要考虑更复杂的例子。假设有一个iOS开发人员团队。 Tony，John和Keith正在使用约15种流行依赖项（例如Alamofire，Kingfisher，ReactiveCocoa等）运行iOS应用程序。不同的编译器 -有些库是用Swift编写的，这意味着每个不同的编译器运行时都与其他运行时不兼容。如果那些开发人员使用不同版本的Xcode，这可能是一个巨大的问题。他们每个人都需要构建自己的框架版本或使用相同版本的Xcode。清理构建时间 -这是最近的热门话题，有时我们需要关心构建时间，尤其是在CI上以及在分支之间切换时。团队认为他们不想花很多时间（例如1个小时）等待发布，所以这个问题可能很关键。存储库大小 -一些开发人员更喜欢在存储库中包含已编译的框架。团队正在使用免费的github计划，因此其最大存储库大小为1GB。在回购中存储框架可能会导致其大小大幅增加，甚至达到5GB左右。即使回购存储限制不成问题，克隆这样的存储库也将花费大量时间。这对于干净的构建时间可能会产生巨大的影响，尤其是在将CI与虚拟机一起使用时。更新框架 -在不进行额外工作的情况下，迦太基会在运行carthage update时重新编译所有框架，或者如果为单个依赖项而运行则仅会编译一个框架。在项目开始时，我们经常这样做。团队也在寻找解决方案以加快这一步。没有免费的午餐……我同意，但是与此同时，我相信有时值得花一些时间来改善日常工具。我花了很多时间来测试依赖项管理器，缓存其工件等。让我告诉您有关维护迦太基框架的三种流行解决方案。在你开始之前如果您不熟悉迦太基，请先查看它的存储库。我不会考虑将迦太基框架直接存储在存储库中。让故事开始……托尼是团队负责人，他决定使用迦太基作为依赖性管理器。他在使用外部框架时为其他开发人员定义了一些规则：将Carthage / Build添加到.gitignore并在存储库中包括Carthage/Checkouts ，首次克隆存储库时，您需要运行carthage bootstrap （重建所有依赖项）。 CI需要为每个管道运行该程序，更新框架时，请仅更新一个框架，例如carthage update ReactiveSwift 。这些规则很简单，但是它们的优缺点又如何呢？优点：免费（每月费用0$ ）仓库的规模永远不会急剧增加缺点：非常长的整洁版本绝对不会重复使用预编译的框架存储库中的其他人的代码 […]

苹果收购BuddyBuild。哦，我的Xcode服务器！: 最初发布于XCBlog。在这里阅读我没想到这将是我2018年的第一篇博客文章。在假期里，我读了“ Apple Buys BuddyBuild”的推文，使我大为震惊，我眨了眨眼，再次阅读了这条推文。我迅速检查了BuddyBuild的Twitter句柄，没有任何鸣叫，在Google上进行了搜索，发现Tech Crunch，CNBC和BuddyBuild博客确认了此消息。考虑到我在iOS DevOps和CI / CD上所做的工作，对于我来说，这个消息无疑是令人振奋的消息。我拿起电话并在Twitter上向丹尼斯表示祝贺。不久之后，我亲自认识了BuddyBuild团队，并把一包T恤交付给我，以参加我在iOS CI Olympics 2017上的工作。 2017年10月的聚会。我在运行iOS CI Olympics 2017时与BuddyBuild联系。我对iOS持续集成和持续交付充满热情，我用20种不同的标准对基于云的iOS 5前5名服务进行了Olympics，BuddyBuild成为了赢家。您可以在此处阅读系列博客文章介绍性博客文章中提到了iOS CI奥运会的目的和规则。玩家表现之一：BuddyBuild 玩家表现二：Bitrise 玩家表现三：TravisCI 玩家表现四：Nevercode 玩家表现五：CircleCI iOS CI奥运会获胜者公告最终的奖牌如下所示： BB = BuddyBuild BR = Bitrise TC = TravisCI NC = NeverCode CC = CircleCI 在评估过程中，我得到了BuddyBuild团队的大力支持，以了解BuddyBuild的关键概念和工作方式。随着BuddyBuild成为获胜者，他们将奥运会的结果发布在BuddyBuild博客上iOS持续集成与部署比较 BuddyBuild给我寄了一些T恤，我把它们分发给Yoox Net-A-Porter的同事。尽管我非常喜欢BuddyBuild，但由于我们使用TravisCI，所以我从未尝试将其用于正在处理的项目，并且我已经建立了完全自动化的端到端管道，以使用Fastlane将iOS应用程序直接部署到iTunes Connect。 […]

如何轻松为iOS项目设置GitLab持续集成: 从未使用过它时，如何使Gitlab-CI / CD 和 Fastlane集成？我们最近在Lodoss团队面对了这一挑战。在本初学者指南中，我将分享我们的分步过程，最初的期望和最终结果。因此，您将能够轻松地自行配置GitLab-CI / CD和Fastlane。我们为什么要持续集成？一切都应有目的地完成。我们考虑了自动化的以下必要要点：自动运行Swiftlint 提高代码质量减少体力劳动自动运行UI和单元测试作业这不是我们需要的全部清单，但是，这是一个很好的起点。在我们的工作中，我们通常使用以下GitFlow ，并且还使用它来自动化CI / CD流程。这是描述我们想要获得的成功案例的序列图：此外，如果有必要（例如，从功能分支进行紧急构建以向管理人员显示新功能），则可以通过使用标签来使用所有这些序列。为什么选择GitLab-CI？我们有GitLab，但找不到使用其他东西的任何理由。因此，我们决定使用它，为什么不使用😎？对我而言，GitLab-CI / CD比Jenkins更面向开发人员。至少因为它是针对管道，标签和分支的，而不像詹金斯那样有工作。而且我们必须使用这些东西来获得必要的工作，而不是不用代码进行配置。 GitLab-CI / CD似乎是一种用于在远程计算机上运行脚本的工具。没有更多，但足够了。一段时间后，我们意识到使用Fastlane并没有关系。因为它能够满足我们的所有需求。结果，我们摆脱了其他工具的束缚。因此，我强烈建议您使用Fastlane代替手动脚本或其他方法。为什么选择Fastlane？ Fastlane是自动化iOS和Android应用程序Beta部署和发布的最简单方法。 🚀它可以处理所有繁琐的任务，例如生成屏幕截图，处理代码签名以及发布应用程序。我们决定使用Fastlane，因为它：让生活更美好减少自动化时间拥有清晰的文档提到的原因还意味着团队中的其他开发人员将很容易学习。当然，简单的过程比复杂的过程要好。设置GitLab-CI和Fastlane 设置您的Xcode项目在Xcode中创建一个新项目。为项目命名。转到项目方案，然后如下图所示打开共享标志： […]

使用Swift的Fastlane | 传递参数| CI: 这篇文章假定您已经熟悉Fastlane。在这里，您可以找到如何将参数传递到车道。我的场景：在我的CI设置中，我将同时使用Jenkins和Fastlane。因此，我需要将参数从命令行发送到我的车道。经过一番努力之后，我终于知道了如何将参数从命令行传递给Fastlane。缺少了什么？。。。文档。我从以下几点开始调查： https://github.com/fastlane/fastlane/issues/11747 https://github.com/fastlane/fastlane/issues/11370 https://github.com/fastlane/fastlane/pull/11401 先决条件： 1.在MacOS上安装fastlane 2.使用以下命令进行设置：捆绑程序执行器fastlane init swift 此时，fastlane正在项目文件夹中创建一些默认文件。（fastlane文件夹，Gemfile和Gemfile.lock）从这一刻起，我们需要集中精力扩展Fastfile.swift 。为此，我更喜欢使用位于以下位置的FastlaneSwiftRunner.xcodeproj ： ./fastlane/swift/FastlaneSwiftRunner/FastlaneSwiftRunner.xcodeproj 在分析Fastlane的快速源文件之后，我尝试查看如何在不带＆参数的情况下从命令行调用车道。我在Fastfile.swift中定义了一些示例函数（通道）：（我已决定根据fastlane swift代码为其中一些格式提供该格式）。 Lane️车道名称匹配不区分大小写。非常好！乍一看，我发现可以使用两种格式调用firstLane ： bundle exec fastlane firstLane或将bundle exec fastlane first 下一步将是看如何将参数传递给车道。在不涉及复杂的Fastfile的情况下，我只想发送样本[key：value]格式。当然，对于secondLane，我们不能使用以下命令： bundle exec fastlane secondLane 因此，在深入研究之后，我设法找出了正确的格式，原因以及如何传递参数。从前面的控制台消息可以看出，只有3种方法被检测为通道。 //不带参数的简单车道，后缀为“车道”。 func firstLane（）//带参数的泳道，作为可选参数，后缀为“ lanewithoptions：” func thirdLane（withOptions […]

iOS的持续集成-艰难的道路: 我们的iOS团队注意到，我们的大部分时间都浪费在了构建和分发项目上。构建和分发的任务非常适合于自动化，因此我们决定对此做一些事情。这就是故事。我们的更大项目之一是着重于旅行的社交媒体应用，其中新功能和错误修复正在不断实施。它的代码库总共包含约350.000行代码： 55％是斯威夫特其中40％是Objective-C 剩下的5％使用C，C ++，Ruby或Shell脚本在具有8 GB RAM的Macbook Pro Retina 2016上，该应用程序的构建和分发时间平均约为30分钟，而在较旧的Mac Mini上，则约为40分钟。如果它不在我们用于开发的机器上运行，或者如果我们想在Macbook上煮一个煎蛋，那将是可以接受的。关于持续集成和持续交付（CI / CD），存在许多选择。这些是我们考虑过的： 1.詹金斯优点：我们的后端和质量检查团队已经在使用它文档内容丰富很多社区的支持经过“实战测试” 缺点：用户界面相当……令人困惑有很多术语它对开发人员不友好某些问题很难调试 2.特拉维斯优点：易于使用免费提供开源软件缺点：仅支持Github（在我们使用Bitbucket时不适合使用入门工具） 3.比特币：优点：面向移动有据可查易于配置和使用缺点：有价位还包括Nevercode，CircleCI，Github Actions和Bitbucket工作流。最后，我们已经选择了Jenkins，因为我们已经让开发人员非常熟悉它。至于测试设备，事实证明，旧的Mac Mini和Macbook Air非常适合（后来用于生产）。

使用Jenkins，Fastlane和TestFlight在iOS中进行持续集成和持续交付-第2部分: 本文概述了从开发人员提交开始的CICD旅程的总体步骤。从多种口味中，CICD管道可以将重点放在Beta构建自动化上。这些步骤分为三步。他们是： A）开发B）集成与部署c）测试 A）发展开发人员完成故事或错误修正。开发人员使用应用程序用户界面和单元测试用例套件测试故事/错误修正。验证后，开发人员将本地更改推送到相应的远程分支。开发人员从功能或错误修正分支创建一个“拉取请求”，再到“开发”分支。审阅者审阅并批准请求请求。开发人员将更改合并到“ develop”分支。 B）整合与部署 Jenkins在’develop’分支上的新提交时得到通知（Webhooks或轮询）。 Jenkins在本地提取最新的代码库并开始构建过程。如果构建成功，则转到下一步。如果构建失败，请通知团队（电子邮件，Slack等）。 3. Jenkins使用Fastlane运行单元测试用例套件。如果构建成功，则转到下一步。如果构建失败，请通知团队（电子邮件，Slack等）。 4. Jenkins增加IPA的内部版本号，并使用Fastlane将其上载到TestFlight。 C）测试 TestFlight将通知发送给所有内部测试人员。内部测试人员使用TestFlight应用程序在其设备中安装最新的Beta版本。内部测试人员结束了故事。

Xcode机器人fast y fastlane🚀Parte 1: 安提斯·纳达·埃斯泰斯特没有任何通俗的口译服务，拉美地区的拉美地区和拉美地区的独奏者，独奏者和独立军团。解决因错误而导致的错误。总体配置和维护的基本知识请一位熟练的工程师提交一份精通的，精湛的手册。

在iOS应用中使用CircleCI 2.0: 我们已经在许多开源项目中使用CircleCI。自2017年末以来，2.0版本开始问世，我们认为现在是与Swift 4.1和Xcode 9.3一起尝试的好时机 2.0版的问题在于它是如此强大，并且具有许多很酷的新功能，例如作业和工作流，但是这需要查阅有关如何迁移配置文件的文档，尤其是“搜索和替换不推荐使用的2.0键” 首先是在config.yml文件夹中创建一个新的.circleci 将现有的circle.yml文件复制到项目存储库根目录中名为.circleci的新目录中。接下来是声明版本和作业将版本：2添加到.circleci / config.yml文件的顶部。对于简单的情况，我们仅使用xcodebuild来构建和测试项目，因此最好在本地进行尝试，以避免进行大量尝试提交来触发CircleCI。你可以看一下这个PR hyperoslo / Cheers＃20 在我们的1.0版配置文件看起来像这样之前 -设置-o pipefail && xcodebuild -project Cheers.xcodeproj -scheme“ Cheers-iOS” -sdk iphonesimulator -destination’platform = iOS Simulator，name = iPhone 8，OS = 11.0′-enableCodeCoverage是测试现在我们应该将pipefail放入shell ，按照CircleCI-Public / circleci-demo-ios：.circleci / config.yml @ master shell：/ bin / bash —登录-o pipefail 现在是实际尝试的xcodebuild ，由于destination参数而导致许多失败 xcodebuild：错误：找不到与提供的目标说明符匹配的目标： {platform：iOS Simulator，OS：11.3}缺少必需的设备说明符选项。 […]