Tag: Circleci

与fastlane和CircleCI的持续集成和交付

我们在Sixt希望分享我们为iOS应用程序进行持续集成和交付的方法。 在过去的一年中，改变我们制作CI和CD的方式对于我们的开发过程至关重要。 首先，让我们从我们的应用程序和团队的一些历史开始，以及如何影响我们对CI提供商的决定。 Sixt应用程序的第一版于2008年发布，我们的团队只有一名iOS开发人员。 那时，CI是没有必要的，并且所有操作都是手工完成的。 在将团队增加到3名成员之后，我们决定从CI开始使用Jenkins。 那时，这是合乎逻辑的决定。 Jenkins是免费的，我们可以将其托管在我们自己的硬件上，一次运行一个构建就可以了。 在2016年，我们决定迁移到TeamCity，并为我们的CI使用两个构建代理。 如今，我们的iOS团队由15位开发人员组成，他们构建了三个公共应用程序Sixt，DriveNow和MyDriver，以及多个内部应用程序。 随着最近几年的快速增长，出现了对新CI服务提供商的需求。 在此博客文章中，我们想分享我们当前的CI / CD管道。 CircleCi 从一开始就很明显，我们希望迁移到基于云的CI提供程序，因为我们自己的硬件的托管和维护花费了开发人员过多的时间。 对我们来说，两个最重要的指标是启动时间和并发性。 在比较了几个提供商之后，我们决定选择CircleCI，因为他们似乎非常满足我们的需求并且看起来已经足够成熟。 单击此链接开始使用CircleCI。 CI管道 现在到我们当前管道的实际外观有趣的部分。 我们正在使用fastlane运行所有脚本，CircleCI只是根据触发它的分支执行不同的通道。 以下是分支和通道如何连接的一般概述： 除了运行上述构建计划外，我们还将在每晚构建中运行整个测试套件。 这包括我们的单元以及UI测试。 在接下来的段落中，我们将完成项目的初始设置和代码签名，创建单个通道并在CirleCI上运行所有程序。 苹果开发者门户 首先，我们需要在门户中创建我们的应用程序标识符。 转到此页面并填写必要的信息。 每个构建配置都需要一个应用程序标识符。 对于此帖子，我们的基本捆绑包标识符是com.name.app，因此我们必须创建以下应用程序标识符： com.name.app com.name.app-dev com.name.app-alpha dev和alpha应用程序标识符是在我们的企业帐户中创建的。 允许在任何设备上部署。 快车道 如上所述，我们将使用fastlane运行脚本。 一个好的做法是使用Gemfile锁定依赖项。 在项目的根目录中创建一个Gemfile，并将fastlane添加为依赖项。 接下来，您将需要根据配置更改包标识符。 转到您的“应用程序目标”->“构建设置”，然后搜索“捆绑标识符”。 它看起来应该类似于： 配置代码签名的最后一步是更改签名设置。 转到常规标签，禁用“自动管理唱歌”，然后为每种配置选择正确的配置文件。 您应该在下拉列表中看到一个符合条件的配置文件。 我们的最终结果如下所示： 测试车道 下一步是创建用于运行我们的不同测试套件的通道。 我们有一条用于单元测试，UI测试的通道，并且可以运行所有通道。 记住要替换您的工作区和方案。 之后，进入项目设置并将用户部署密钥添加到项目非常重要。 这允许快速通道匹配来克隆我们的证书存储库。 再次在这里，我们建议您使用bot github帐户添加用户ssh密钥。 […]

使用Fastlane生成CircleCI测试摘要

创建人： Jeremy Sherman 持续集成的核心是运行测试。 每当测试失败时，您都想知道为什么要尽快解决，以便您进行更正。 每当CI构建失败时，您都希望查看失败的测试及其失败方式。 CircleCI的“测试摘要”功能将此信息放在首位，因此您可以直接响应测试失败，而不会遇到任何麻烦。 诀窍是按预期方式为CircleCI提供测试信息。 构建日志可能很好启动。 您展开失败的步骤，滚动到页面的末尾，然后向上滚动直到遇到测试失败。 这还不错。 首先。 但是，对于一个足够大的项目，构建和测试日志会变得太长而无法在网页上就地查看。 然后，您会发现自己先下载了日志文件。 有时，失败的测试实际上并不是在文件末尾附近。 然后，您会四处寻找它。 在一个长期项目中的许多开发人员中，这段时间和精力加起来。 如果要构建iOS应用程序，并且将粘贴的示例配置复制并粘贴到CircleCI上，那么您应该会感到幸运。 但是，在以下情况下，您将希望更好地了解“测试摘要”功能正在寻找什么： 您的测试摘要会省略您想要的信息，例如棉绒输出。 测试摘要不适用于您，您想修复它。 您不是在使用Fastlane构建iOS应用，其他示例配置之一无法满足您的需求。 CircleCI的“收集测试元数据”文档指出了一件大事： 使用JUnit的XML格式报告测试。 store_test_results步骤参考引用了另一个： 您的测试报告应位于另一个“所有测试”目录的子目录中。 此子目录名称用于标识测试套件。 不过，还有一个要求是我从未在任何地方看到过文档： JUnit XML测试报告文件必须在字面上具有xml扩展名。 对于测试摘要，文件名的其余部分似乎无关紧要，但是如果您使用错误的路径扩展名，则不会看到任何测试摘要。 您将得到一个目录布局，例如： /用户/蒸馏器/项目/ └──快车道 └──test_output └──xctest └──junit.xml3目录，1个文件 这打勾了所有框： XML文件： junit.xml “测试套件”目录： xctest “所有测试套件”目录： test_output （Fastlane仅生成单个测试报告，因此，“在文件夹中报告”的嵌套看起来有点愚蠢。） 扫描提供了许多配置旋钮。 您可以通过运行fastlane action scan查看完整列表的表及其默认值。 我们需要安排三件事： 报告格式：JUnit 报告文件名：junit.xml 报告文件应写入的目录：fastlane / test_output […]

在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}缺少必需的设备说明符选项。 […]

DevOps的旅程-第1部分

我最近荣幸地加入了Pillar ，这是他们DevOps团队的一个令人兴奋的新项目。 作为一个相对初级的开发人员，这始终是发现的旅程，而且就是黑桃白！ ♠️ 我们的任务是接受一个React-native项目，并创建一个可以利用自动化测试框架的持续集成/持续交付（CI / CD）管道。 此博客涉及过程的CD部分。 另一个博客将详细介绍管道的“测试自动化”部分。 所以我们的任务听起来很容易，呵呵。 但是为什么听到我问的为什么要建立CD / CI管道呢？ 这将增加什么好处？ 首先，如果您不确定这些术语的含义和区别，请查看这篇非常有用的文章（https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd）。 CI / CD管道有何用处？ 简而言之，它使开发人员的生活更加轻松。 它节省了开发人员的时间 ，为他们提供了快速的反馈，并简化了整个部署过程，包括构建应用程序， 测试应用程序，将应用程序归档在二进制存储库中以及将两者都部署到必要的测试平台。 所有这些都可以通过自动CI / CD管道来处理，从而节省了开发人员的时间。 这使开发人员感到高兴，并使他们腾出精力去做自己最擅长的事情，从而开发和创造了魔术。 ✨ 因此，自动化的管道可以节省时间。 真好！ 但是，那并不是它的亮点。 它的亮点在于它可以设置可靠，重复地发布代码的过程 ☀️作为开发人员的智能和能力，他们是人类。 这意味着他们会感到疲倦并可能犯错，而自动化的流程可以帮助减轻这种情况。 这是描述CI / CD的引号。 确实是一个简单的报价，但要点。 创建可重复，可靠的过程来发布软件 因此，这些是我们需要通过React Native项目实现的总体目标： 依赖管理 建立业务流程并发布 结合以上内容并使用CircleCI自动化我们的管道 我们从一个具有许多依赖关系的React Native项目开始。 以下是针对我们项目的主要问题的简要列表： 我们的应用程序需要许多独特的依赖项，例如Signal Server 我们有自己的存储库，需要包含在Artifactory中存档的存储库 iOS特定的依存关系：cocoapods 依赖性管理问题＃1：管理许多npm依赖性 要解决此问题，我们使用了CircleCI和Artifactory 。 CircleCI用于预订我们的应用程序的构建。 我们使用它来开始我们的应用程序构建，正如我们稍后将要看到的，我们也使用它来关闭我们的应用程序构建。 […]

CircleCI 2.0和iOS代码签名

没有Fastlane比赛 在TechOps中，我们使用CircleCI来测试和部署iOS应用。 最初的CircleCI 1.0很好，但是他们推出了2.0版，并停止了对1.0版以后的Xcode版本的支持。 当我开始迁移到2.0时，我遇到了以下注意事项： 在CircleCI 2.0上，唯一支持代码签名的方法是使用上述文档中所述的Fastlane Match。 我很惊讶。 你惊喜吗？ 我喜欢Fastlane。 这是iOS开发工具发生的一件好事。 但是我不想在CI上使用Match，因为： 它需要带有加密证书的单独回购。 好。 但是密码仍然应该存储在CI环境变量设置中。 那么为什么身份不应该呢？ 依靠互联网连接的不必要步骤 这是对Google产品的不可预测的依赖； 我们不知道它将活多久 可以说，如果我们转向Match，那么我们将不再依赖CI提供者。 但是事实并非如此，迁移文档建议使用特殊操作： 尽管其他快速通道操作可以轻松地与一组xcodebuild命令互换，但“匹配”步骤提供了一种处理签名身份和配置文件的概念，这些概念有时可能会过时。 无论如何，我已经弄清楚了如何在不使用Match的情况下使用代码签名。 解 TL; DR：很难说，但是您必须将证书和配置文件编码为base64表示形式，将其设置为env，然后将其解码回文件。 macOS钥匙串 将证书和私钥导出为p12文件，设置证书密码。 从Apple Dev Center获取配置文件（使用该身份签名）。 编码文件 在macOS Terminal中，将Certificates.p12编码为base64，然后将结果复制到剪贴板： $ base64 -i Certificates.p12 | pbcopy 并使用相同的命令来解码.mobileprovision文件。 CircleCI上下文 要在2.0中存储环境值，我们必须使用上下文。 转到组织设置→上下文→资源→添加资源。 添加具有某些名称的变量（例如Certificates ），然后将先前复制的值粘贴到Value字段中。 CircleCI配置YAML 现在，我们需要取回这些文件。 在.circleci/config.yml使用以下步骤： 现在，我们将证书和个人资料放在正确的位置。 进口证明书 现在，我们需要将签名身份添加到CI钥匙串中，CircleCI上不再存在。 我提到了setup_circle_ci特殊操作，我们将使用它来创建钥匙串，正如我们从其源代码中知道的那样。 我们必须添加以下before_all通道： […]

所以我想部署一个二进制文件

你不可以过去！ 到目前为止的故事 最初，宇宙是被创造出来的。 这使很多人非常生气，被普遍认为是一个坏举动……开玩笑！ 这一切都是从最近开始的。 确切地说，在星期四晚上6:42 pm。 我有一些带宽，因此决定解决我团队长期以来遇到的麻烦 -使用CircleCI环境进行手动部署。 直到星期四晚上，我们对于使用（请参阅：构建和维护）不同的工具或利用完全独立的服务来达成最终目标的想法不尽相同。 理想情况下，我们应该能够利用CircleCI API并以此方式触发作业。 不幸的是，截至撰写本文时， 如果您正在使用CircleCI 2.1和Workflows ，则目前无法 （通过API） 触发单个作业 。 但是，我们手头有一个更简单的解决方案，这对我们来说是未知的。 工作流程 根据CircleCI的文档，为了通过更快的反馈，更短的重新运行和更有效的资源利用来提高软件开发的速度，我们应该配置工作流 。 我们已经使用了它们，它们为我们服务很好。 但是有一个我们不知道的配置密钥- type: approval 。 围绕它的文档措辞混乱，难以理解。 但是经过几次重读后，我到达了那里。 批准书 在CircleCI工作流下为工作分配 approval类型时，“工作”在config.yml必须是唯一的。 例如，如果您定义了三个主要作业： 建立 测试 部署 每个都在您的工作流程中运行，那么手动触发器必须命名为上述以外的名称。 还必须仅在您的工作流中定义它。 此外，为了使手动触发器真正起作用 ， 必须依赖于它的另一个后续工作。 我将触发器命名为deploy-branch 。 只有在打开CircleCI Web UI并手动启动它时，才会运行此程序。 换句话说，当一个人给予批准时 。 结果 一旦我继续进行工作，并调整了工作流程以包括type: approval为roval的工作，我们便有了一个真正的手动触发器。 它没有精美的界面，例如Github标签或Slackbot命令，但是它确实做到了上面所说的。 结论 作为行业和专业的iOS开发人员，我在摆放我们的CI环境的同时，真正地走出了自己的舒适区。 […]