面向IOS开发者的AWS和DevOps入门指南全绝不原创的飞龙

本章面向iOS应用开发初学者。如果你是iOS开发者或者有开发iOS应用的经验，可以跳过。

为了开发iOS应用，苹果提供了几种工具和资源。iOS应用可以用原生编程语言开发，如Swift或Objective-C等跨平台语言。

在本章中，我将介绍iOS应用开发的要求和基本构建模块，同时通过使用Swift构建一个示例应用并在iOS设备和iOS模拟器上测试该应用，引导您完成整个过程。

作为一名iOS开发者，你需要一台macOS设备和一个苹果开发者账号才能开始开发。

要开始iOS开发，需要一台Mac。它有笔记本和台式机两种版本。目前的笔记本版本有MacBookAir和MacBookPro，台式机版本有iMac、MacPro、Macmini。在图1-1中可以看到一些Mac型号。

图1-1

比较各种Mac型号

你可以免费注册成为苹果开发者。你只需要一个苹果ID。有了免费的开发者账户，你就可以在你的Mac上安装Xcode(我们将在下一节介绍)、iOS开发文档、样本代码、苹果开发者论坛和错误报告。你也可以在设备上测试你的应用。免费的苹果开发者账号足够本地测试和开发。但是，要分发应用，您需要注册苹果开发者计划。

苹果开发者计划是一个付费会员计划，按年计费。如果您对创建应用并在AppStore上发布感兴趣，这是必需的。关于苹果开发者计划的更多细节可以在苹果网站上找到，如图1-2所示。

图1-2

苹果开发者计划

Swift是苹果公司在2014年开发的一种编程语言。开发Swift的目的是找到C、C++和Objective-C等基于C的语言的替代品。凭借其语法的表达性质，Swift拥有开发人员想要的现代功能，并使iOS应用开发更容易。

有各种资源可用于学习Swift然而，苹果公司开发的应用SwiftPlaygrounds可以让你以有趣和互动的方式学习Swift。目前该应用适用于iPad和Mac，可以从AppStore下载，如图1-3所示。

图1-3

斯威夫特游乐场

除了支持在MacOS系统上开发之外，Xcode还是由Apple开发的集成开发环境(IDE),它拥有您在所有AppleOS平台上开始iOS开发所需的一切。它包括代码编辑器、调试器等功能。它还附带了一个模拟器，使您能够在真实的iOS设备上构建和测试您的应用，而不需要物理iOS设备。

在接下来的几节中，我将向您展示如何安装Xcode并使用它来构建和部署iOS应用。

我将在macOSBigSur上安装Xcode12，这两个版本目前分别是Xcode和macOS的最新版本。要安装，去Mac上的AppStore搜索Xcode，如图1-4所示。

图1-4

AppStore上的Xcode搜索结果

单击安装图标，等待安装完成。

安装后，启动Xcode，你应该会看到一个欢迎页面，如图1-5所示。

图1-5

启动Xcode

接下来，我将通过创建一个示例应用向您展示如何使用Xcode创建应用。

安装Xcode后，您就可以开始构建iOS应用了。我将从使用Xcode提供的应用模板开始，然后添加自定义代码来定制应用。

Xcode提供了样本模板，可以轻松开始构建应用。这些模板可以通过创建一个新的Xcode项目来访问(图1-5)，并显示不同的可用模板。对于我正在构建的样例app，我会选择iOS和App，如图1-6所示。

图1-6

为Xcode项目选取模板

图1-7

图1-8

填写新Xcode项目的详细信息

创建之前，必须选择工作站上保存应用的文件夹位置。一旦完成，就创建了一个应用，如图1-9所示。

图1-9

已创建示例应用项目模板

如图1-9所示，由于在图1-8中创建项目时选择了Swift语言，所以应用模板是用Swift语言编写的。

让我们看看现成的Swift代码，看看它在做什么。

importSwiftUIstructContentView:View{varbody:someView{Text("Hello,world!").padding()}}structContentView_Previews:PreviewProvider{staticvarpreviews:someView{ContentView()}}Listing1-1ContentView.swift清单1-1中的代码片段负责显示在iOS设备上的视图；正如所见，这个iOS应用模板简单地打印出“你好，世界！”。

importSwiftUI@mainstructSampleAppApp:App{varbody:someScene{WindowGroup{ContentView()}}}Listing1-2SampleAppApp.swift清单1-2显示了应用的入口点，如图所示，它通过调用ContentView()(在不同的文件ContentView.swift中定义)来运行应用，如清单1-1所示。

在配置项目时选择SwiftUI界面，可以在代码中对内容视图进行更改时实时预览应用。

让我们来看一个默认应用的预览。从运行目标菜单中，选择您想要使用的iOS模拟器，如图1-10所示。

图1-10

选择iOS模拟器

选择iPhone11模拟器，预览显示在模拟的iPhone11上，如图1-11所示。如图所示，实时预览让您能够在运行构建之前查看应用视图的外观。当在代码中对应用视图进行更改时，预览也会更新。

图1-11

iPhone11模拟器上的默认应用预览

至此，您已经使用了创建Xcode项目时作为所选模板的一部分提供的默认应用，现在让我们添加一个自定义Swift代码。

用清单1-3中的代码替换contentview.swift的内容。

应用图标是应用的可视化表示，显示在主屏幕、AppStore和各种其他位置，如设置和搜索结果。由于用途多样，苹果要求应用图标有不同的大小。

进入Assets.xcassets，拖动图标到各自的槽位，即可添加App图标，如图1-12所示。

图1-12

添加应用图标

我们已经创建了一个定制的示例应用代码，并为该应用添加了一个图标。我们已经准备好了应用的所有基本构件。现在我们将构建应用并在iOS设备上运行它。

让我们看看这个应用在物理iOS设备上是什么样子的，比如iPhone。

要在物理iPhone上构建应用，必须将其插入用于开发的Mac工作站。一旦将设备插入工作站，就可以选择它作为构建目标。示例如图1-13所示。

图1-13

选择用于构建的物理iOS设备

要在已连接的物理iOS设备上开始构建，请单击设备选项左侧的播放标志按钮(图1-13)。可能会显示iOS钥匙圈提示，如图1-14所示。这需要Mac工作站密码(不是你的AppleID密码)。

图1-14

构建完成后，带有图标的新应用就会安装在iPhone上。

图1-15显示了在物理iPhone上启动应用时的用户界面示例。

图1-15

在物理iPhone上启动示例应用

就像在物理设备上构建和运行应用一样，让我们在模拟器上运行应用。

要在模拟器上构建，应该像选择物理iOS设备一样选择目标设备模拟器，并开始构建，单击设备选择左侧的播放符号按钮，如图1-13所示。

一旦构建完成，模拟器将显示安装了应用的模拟iPhone。使用光标滚动模拟iPhone的页面，并启动已安装的应用。图1-16显示了应用的图标以及在iPhone11模拟器上启动时的样子。

图1-16

在iPhone11模拟器上启动示例应用

到目前为止，我已经向您展示了如何使用Xcode用户界面构建应用；但是，您也可以通过命令行界面使用Xcode的命令行工具xcodebuild与Xcode进行交互。

xcodebuild允许您从命令行对Xcode项目执行构建、测试和归档等任务。有了它，您可以在命令行上从用户界面执行我们之前执行的所有任务，这为自动化打开了大门。

它预装了Xcode，所以在macOS工作站上安装它不需要额外的操作。在您的工作站上运行xcodebuild-usage命令来查看一些基本的使用信息，如清单1-4所示。

$xcodebuild-usageUsage:xcodebuild[-project][[-target]...xcodebuild[-project]-scheme[-destination]...xcodebuild-workspace-scheme[-destination]...xcodebuild-version[-sdk[|][-json][]]xcodebuild-list[[-project]|[-workspace]][-json]xcodebuild-showsdks[-json]Listing1-4xcodebuild-usagetruncatedoutput要查看包括所有可用选项在内的更多使用细节，运行xcodebuild-help并查看输出，如清单1-5所示。

$xcodebuild-helpUsage:xcodebuild[-project][[-target]......xcodebuild-version[-sdk[|][-json][]]xcodebuild-list[[-project]|[-workspace]][-json]xcodebuild-showsdks[-json]...Options:-usageprintbriefusage-helpprintcompleteusage-verboseprovideadditionalstatusoutput-licenseshowtheXcodeandSDKlicenseagreements-checkFirstLaunchStatusCheckifanyFirstLaunchtasksneedtobeperformed-runFirstLaunchinstallpackagesandagreetothelicense-projectNAMEbuildtheprojectNAME-targetNAME...Listing1-5xcodebuild-helptruncatedoutput您可以使用xcodebuild在前面几节创建的示例应用中导航，如清单1-6和1-7所示。

首先，您可以列出关于示例应用项目的所有信息。

$xcodebuild-list-projectSampleApp.xcodeprojCommandlineinvocation:/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild-list-projectSampleApp.xcodeprojUserdefaultsfromcommandline:IDEPackageSupportUseBuiltinSCM=YESInformationaboutproject"SampleApp":Targets:SampleAppSampleAppTestsSampleAppUITestsBuildConfigurations:DebugReleaseIfnobuildconfigurationisspecifiedand-schemeisnotpassedthen"Release"isused.Schemes:SampleAppListing1-6Listingalltheinformationaboutaproject接下来，您可以在工作区中列出方案。

$xcodebuild-list-workspaceproject.xcworkspaceCommandlineinvocation:/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild-list-workspaceproject.xcworkspaceUserdefaultsfromcommandline:IDEPackageSupportUseBuiltinSCM=YESInformationaboutworkspace"SampleApp":Schemes:SampleAppListing1-7Listingallschemesinyourworkspace摘要本章向您展示了iOS应用开发的基本构件；通过构建自己的应用并将其部署到实际的iOS设备和iOS模拟器上，您获得了实践经验。

在下一章中，我们将更进一步，探索如何将构建的应用提交到AppStoreConnect进行分发和/或最终提交到Apple的AppStore。

本章面向iOS应用开发初学者；如果你是iOS开发者或者有开发iOS应用的经验，可以跳过。

在前一章中，我们看到了如何使用Xcode在物理iPhone设备和模拟器上构建和运行应用。我们将进一步探索如何通过上传到AppStoreConnect来分发之前构建的应用。

在将应用版本上传到AppStoreConnect之前，必须为应用注册一个标识符。标识符用于唯一地标识一个应用，以便没有两个应用共享一个标识符。

可以从苹果开发者计划门户创建新的标识符。从门户可以进入证书、标识&简介页面，如图2-1所示。

图2-1

应用开发者计划门户

可以创建一个新的标识符，如图2-2所示。

图2-2

创建新的标识符

用户可以创建不同类型的标识符，如图2-3所示。应该创建一个应用ID。

图2-3

选择标识符类型

目前有两种类型的应用id。选择如图2-4所示的类型。

图2-4

选择应用ID类型

应该提供描述和ID名称。示例如图2-5所示。

图2-5

提供ID名称和描述

AppStoreConnect是一个平台，用于管理AppStore上应用的所有信息。最重要的是，应用通过AppStoreConnect提交到苹果的AppStore。您可以通过Apple开发者计划帐户访问AppStoreConnect。入口如图2-6所示。

图2-6

应用商店连接

必须先创建应用，然后才能将应用内容上传到AppStoreConnect。这将作为应用在AppStore上的占位符，并且可以在此配置应用的所有信息。

要创建应用，请导航至AppStore连接应用页面并创建一个应用，如图2-7所示。

图2-7

创建新应用

要创建应用，选择之前在图2-5中创建的包ID，并提供应用详细信息。图2-8显示了我提供的申请细节。

图2-8

提供新的应用详情

图2-9

AppStoreConnect中的新应用

尽可能多地添加应用的详细信息。为应用输入的一些信息是截图、应用类别、定价和可用性、应用隐私、版本发布等。正如我们将在下图中看到的那样。

虽然有各种工具可以创建屏幕截图，但当应用在模拟器上运行时，iOS模拟器可以用于截图。图2-10显示了在AppStoreConnect上添加截图的位置。

图2-10

在AppStoreConnect中添加新应用的屏幕截图

图2-11显示了如何配置应用类别的示例。通过从左侧菜单中选择常规应用信息，可以访问应用类别。

图2-11

为您的应用配置类别

图2-12显示了如何配置应用的价格和可用性。

图2-12

为您的应用配置价格和可用性

图2-13显示了如何配置应用的隐私策略。

图2-13

为您的应用添加隐私策略

图2-14显示了发布应用新版本的配置示例。

图2-14

为应用添加版本发布设置

此时，您已经在AppStoreConnect中创建了一个应用，并配置了所有应用元数据。现在您可以从Xcode上传构建到AppStoreConnect了。

为此，您需要创建一个完整的应用归档。我们通过从模拟器列表中选择任何iOS设备来实现，如图2-15所示。

图2-15

为完整的应用档案选择模拟器

在创建归档之前，验证Xcode上配置的捆绑包标识符是否与AppStoreConnect上配置的捆绑包ID相匹配，如图2-5所示。这一点可以在Xcode上app的通用设置中验证，如图2-16。

图2-16

验证捆绑ID

一旦验证了包ID，就可以创建完整的归档文件了。创建档案时，选择产品档案，如图2-17所示。

图2-17

创建完整的应用归档

归档完成后，会弹出一个新窗口，如图2-18所示，显示已创建的归档。还将列出多个归档文件(如果可用)，以及该归档文件的版本和创建日期。

接下来选择分发App，如图2-18所示。

图2-18

要分发的应用归档

要分发应用，您必须选择分发方式。由于这里的目标是上传到AppStore，你选择AppStoreConnect，如图2-19所示。

图2-19

将应用上传到AppStoreConnect

若要将iOS应用上传到AppStoreConnect，需要Apple分发证书。如果Xcode找不到证书，例如，如果您是第一次上传应用，它会尝试为您创建一个新的，您会得到如图2-20所示的提示。

图2-20

创建Apple分发证书

Xcode生成证书后，它会将证书储存在Keychain中，但也让您有机会导出证书p12文件以便安全保管。你会得到如图2-21所示的提示。

图2-21

导出Apple分销证书

上传开始前，会提示你AppStore分发选项，比如包含iOS内容的位代码，上传App符号；选择这些选项。

此外，系统会提示您选择签名选项。选择让Xcode自动管理签名的选项。

一旦应用上传开始，你应该会看到一个进度条，如图2-22所示。

图2-22

正在上传应用

一旦上传完成并且没有错误，您将会看到上传成功消息，如图2-23所示。

图2-23

应用上传完成

接下来，我们将探讨如何对上传的新应用进行测试，最后，如何提交应用进行审查。

当上传的版本在AppStoreConnect上可用时，您可以在最终提交到AppStore之前对应用进行可选的测试。让我们来探索一下如何在苹果的AppStoreConnect上完成这些。

测试版测试不是iOS应用开发流程中的必要步骤。然而，苹果提供了一个名为TestFlight的工具，可以用于beta测试。通过TestFlight，你可以邀请实际用户下载并安装你的应用到他们的设备上，以便在公开发布之前收到反馈。

要为beta测试添加测试人员，您可以转到TestFlight选项卡并选择build。您可以选择添加单个测试人员或一组测试人员，并向测试人员提供信息，如图2-24所示。

图2-24

添加生成测试信息

如果您选择添加单个测试人员的选项，您将得到一个弹出窗口，如图2-25所示，您应该在这里提供测试人员的姓名和联系方式。

图2-25

向构建中添加测试人员

添加测试人员后，添加测试信息并提交测试进行审核，如图2-26所示。

图2-26

提交beta测试以供审查

该流程的最后一步是提交应用进行审核。滚动到AppStoreConnect上的Build部分，要提交你的应用进行审核，首先选择一个已经上传到AppStoreConnect的Build，如图2-27所示。

图2-27

选择上传的版本

一旦选择并添加了一个构件，提交审查按钮被激活，如图2-28所示。

图2-28

提交应用进行审核

在此提交应用会在应用可用之前启动Apple的审查。

本章在前一章的基础上总结了iOS开发的基础知识，并向您展示了如何与AppStoreConnect进行交互，以便从您的工作站上传应用版本、执行beta测试以及提交供审查。

在下一章中，我们将通过回顾DevOps、AWS云的基础知识来了解DevOps，您将了解不同的AWSDevOps产品。

业界对DevOps有不同的定义，但所有这些定义大多指向相同的原则。AWS对DevOps的定义如下:

DevOps是文化哲学、实践和工具的结合，它提高了组织高速交付应用和服务的能力:以比使用传统软件开发和基础设施管理流程的组织更快的速度发展和改进产品。

DevOps概念的主要目标是改进软件开发生命周期。为了实现这一点，它引入了不同的方法、工具、过程等。

AWS为DevOps的各个方面提供了丰富的工具，它还与第三方工具集成，为用户在AWS上实践DevOps提供了广泛的选择。在这一章中，我将介绍一些基本的AWS云概念，然后我们将探索AWS上用于实践DevOps的主要工具和技术。我将介绍这些服务，并演示如何在AWS管理控制台上开始使用这些服务。我们还将介绍一些与第三方工具的常见集成。

持续集成的概念是让开发人员在源代码控制管理工具中定期合并代码，并频繁运行自动化测试。这允许您快速检测软件问题，从而提高软件交付的整体质量。

让我们在接下来的章节中探索AWS提供的不同的持续集成工具。

简而言之，AWSCodeCommit是一个托管的私有git存储库服务。作为托管AWS服务，您不需要管理底层硬件或配置来支持托管私有git存储库，因此它是安全的和高度可伸缩的。作为一个git存储库，它支持标准的git功能，因此它可以与现有的基于git的工具一起工作，比如gitcli、GUI客户端等。

使用AWSCodeCommit作为您的私有git存储库有很多好处；所有这些都可以归纳为以下五个要点:

创建CodeCommit存储库有多种方式，例如通过AWS管理控制台、AWSCLI、AWSSDKs等。；然而，我将展示开始使用AWS管理控制台界面的最简单方法。

图3-1

AWS管理控制台上的AWS代码提交搜索

启动CodeCommit页面的另一个选项是从AWS管理控制台的开发者工具部分选择CodeCommit，如图3-2所示。

图3-2

从开发人员工具部分选择CodeCommit

启动CodeCommit网页后，创建一个引用图3-3的存储库。

图3-3

开始代码提交存储库创建

提供库名，可选描述，选择创建，如图3-4所示。

图3-4

创建代码提交存储库

创建存储库之后，下一步是连接到您的存储库并开始使用它，如图3-5所示。要进行连接，您需要使用现有的基于git的工具。

图3-5

连接到代码提交存储库

AWSCodeBuild是云上的托管构建服务器。它提供了一个计算环境来编译代码，运行测试和产品工件。CodeBuild从源代码提供者处获取源代码，并执行YAML规范文件(通常称为Buildspec)中定义的操作。对于源代码提供者，CodeBuild目前支持亚马逊S3、AWSCodeCommit、GitHub、Bitbucket和GitHubEnterprise。

从AWS管理控制台，在搜索栏中搜索CodeBuild，如图3-6所示。

图3-6

AWS管理控制台上的AWS代码构建搜索

您也可以在AWS管理控制台的开发者工具部分选择CodeBuild，如图3-2所示。

在CodeBuild页面上，创建一个构建项目，如图3-7所示。

图3-7

开始创建代码构建项目

一个CodeBuild项目支持不同的源代码。将由CodeBuild编译或构建的源代码将存储在这个源代码库中。对于不需要源代码的构建，不需要配置源代码。这种构建的一个例子是当构建被配置为连接到外部位置以获取构建所需的资源时。

如图3-8所示，没有为我将要创建的项目配置任何源。

图3-8

正在配置代码生成项目的源代码

如前所述，CodeBuild项目提供了一个使用容器映像执行构建操作的计算环境。您可以选择使用托管AWS代码构建映像或提供自定义docker映像。如图3-9所示，我将使用托管代码构建映像。

图3-9

代码构建项目计算环境

CodeBuild项目需要生成规范。当使用项目的源代码提供者时，YAML构建规范文件可以存储在代码存储库中，并且在项目中配置名称和位置，默认情况下CodeBuild将查找文件名buildspec.yaml。构建规范命令也可以直接提供给项目，如果项目没有配置任何源代码，这是特别需要的，我们正在创建的CodeBuild项目就是这种情况。

下面的清单显示了一个示例构建规范。定义的每个阶段按顺序执行，每个阶段中的命令也按顺序执行。

version:0.2phases:install:commands:-echoEnteredtheinstallphase...-apt-getupdate-y-apt-getinstall-ymavenpre_build:commands:-echoEnteredthepre_buildphase...build:commands:-echoEnteredthebuildphase...-echoBuildstartedon`date`post_build:commands:-echoEnteredthepost_buildphase...-echoBuildcompletedon`date`Listing3-1CodeBuildbuildspecification复制此示例，并作为构建规范提供，如图3-10所示。

图3-10

代码构建构建规范

将其余设置保留为默认设置，创建CodeBuild项目，如图3-11所示。图3-11中选中的CloudWatch日志选项确保构建日志流至AmazonCloudWatch以方便访问，并为进一步的日志处理打开大门。

图3-11

创建代码构建项目

AWSCodeArtifact是一个工件存储库，用于存储、发布和共享软件开发过程中使用的软件包。这是一项全面管理的服务；因此，不需要管理基础架构和许可证。

使用AWSCodeArtifact，您可以发布私有包供开发人员使用，也可以将其配置为从公共工件存储库中获取。当配置为从公共工件库中获取时，使用AWSCodeArtifact的额外优势是定义访问控制和验证软件包的能力。它与常见的包管理器一起工作，如Maven、Gradle、npm、yarn、twine、pip和NuGet。

让我们看看如何创建AWS代码工件库。我将在AWS管理控制台的开发者工具部分选择CodeArtifact，如图3-2所示，然后开始创建库，如图3-12所示。

图3-12

开始创建CodeArtifact仓库

您将看到如图3-13所示的页面，在这里您可以填写存储库名称。如果要配置该库连接上游公共库，也可以在这里配置上游库，如图3-13所示。

图3-13

提供存储库详细信息

CodeArtifact中有一个域的概念。这是存储库的逻辑分组，每个CodeArtifact存储库必须是域的一部分。一个域也可以在另一个AWS帐户中，这使得在多帐户AWS环境中管理大量代码工件存储库变得容易。可以创建或选择一个域，如图3-14所示。

图3-14

创建存储库域

创建域后，下一步是检查和创建存储库，如图3-15所示。

图3-15

审查和创建CodeArtifact存储库

对于初始连接，会显示不同通用软件包管理器的连接说明，例如，创建后的npm。

正如上一节所讨论的，持续集成涵盖了开发人员如何在源代码控制管理工具中定期合并代码，并运行频繁的自动化测试。连续交付通过部署代码变更而更进一步。代码变更可以被部署到开发和/或测试环境中，这确保您总是拥有一个已经被构建和测试的生产就绪的工件。

AWSCodeDeploy是一项自动化软件部署服务。借助CodeDeploy，您可以自动部署到在AmazonElasticComputeCloud(AmazonEC2)实例、AmazonElasticContainerService(AmazonECS)、本地服务器和AWSLambda功能上运行的应用。

要使用CodeDeploy，您需要在一个YAML规范文件中定义应用应该如何部署，这个文件通常被称为appspec.YAML；CodeDeploy使用这个规范文件来完成应用部署。对于AmazonEC2和内部部署，CodeDeploy代理必须安装在应用服务器上，以便CodeDeploy管理部署，但对于AmazonECS和AWSLambda等其他计算平台，CodeDeploy代理不使用，因为它们是托管的AWS服务。

应用规范文件根据目标计算平台采用不同的形式，例如AmazonEC2、AWSLambda等。让我们看看不同计算平台的规范文件示例。

清单3-2显示了部署到AmazonEC2或本地服务器的示例规范文件。

version:0.0os:linuxfiles:-source:Config/config.txtdestination:/webapps/Config-source:sourcedestination:/webapps/myApphooks:BeforeInstall:-location:Scripts/UnzipResourceBundle.sh-location:Scripts/UnzipDataBundle.shAfterInstall:-location:Scripts/RunResourceTests.shtimeout:180ApplicationStart:-location:Scripts/RunFunctionalTests.shtimeout:3600ValidateService:-location:Scripts/MonitorService.shtimeout:3600runas:codedeployuserListing3-2ExampleappspecforAmazonEC2oron-premisesdeployment清单3-3显示了一个AWSLambda功能部署的示例规范文件

version:0.0Resources:-myLambdaFunction:Type:AWS::Lambda::FunctionProperties:Name:"myLambdaFunction"Alias:"myLambdaFunctionAlias"CurrentVersion:"1"TargetVersion:"2"Hooks:-BeforeAllowTraffic:"ValidateBeforeTrafficShift"-AfterAllowTraffic:"ValidateAfterTrafficShift"Listing3-3ExampleappspecforAWSLambdadeployment清单3-4显示了一个AWSLambda功能部署的示例规范文件。

version:0.0Resources:-TargetService:Type:AWS::ECS::ServiceProperties:TaskDefinition:"arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1"LoadBalancerInfo:ContainerName:"SampleApplicationName"ContainerPort:80Hooks:-BeforeInstall:"ValidateBeforeInstall"-AfterInstall:"ValidateAfterInstall"-AfterAllowTestTraffic:"ValidateAfterTestTraffic"-BeforeAllowTraffic:"ValidateBeforeProdTraffic"-AfterAllowTraffic:"ValidateAfterProdTraffic"Listing3-4ExampleappspecforAmazonECSdeploymentAWS代码管道使用AWSCodePipeline，您可以按照阶段和操作的顺序编排和自动化组成软件发布过程的所有步骤和操作。CodePipeline集成了各种AWS服务和第三方工具，使您能够创建从源代码到部署的整个软件交付过程自动化的管道。

要开始创建管道，我将在AWS管理控制台的开发者工具部分选择代码管道，如图3-2所示，然后开始创建管道，如图3-16所示。

图3-16

开始创建管道

因为管道将代表您执行操作，所以它需要一个serviceIAM角色来定义管道在AWS帐户中拥有的权限。在AWS管理控制台上创建管道时，可以为您创建所需的IAM角色，或者您可以选择现有的IAM角色，如图3-17所示。

图3-17

创建代码管道服务角色

现在，您开始定义管道的结构。管道的第一级是源级，它将定义应用源代码的存储位置。对于源代码阶段，AWSCodePipeline支持亚马逊ECR、AWSCodeCommit、亚马逊S3和第三方工具，如Bitbucket和GitHub。在图3-18中，AWSCodeCommit被配置为管道的源。

图3-18

将AWS代码提交配置为管道源阶段

接下来，我们配置一个构建阶段。对于构建阶段，CodePipeline支持AWSCodeBuild、CloudBees、Jenkins和TeamCity。图3-19显示了在构建阶段使用AWSCodeBuild。

图3-19

将AWS代码构建配置为管道构建阶段

构建阶段之后是部署阶段。在部署阶段，从构建阶段检索构建的工件，然后进行部署。您可以有多个代表不同环境的部署阶段。

CodePipeline集成了各种AWS服务和工具，以支持您的应用部署。

图3-20显示了在AWS管理控制台上创建部署阶段时支持的部署提供者。

图3-20

代码管道部署提供程序

虽然代码管道在初始创建期间至少需要两个阶段，但部署阶段不是必需的，可以在管道初始创建期间跳过。参见图3-21了解如何跳过部署阶段。

图3-21

跳过添加部署阶段

在配置完所有阶段并与所需工具集成之后，就可以创建管道了。如图3-22所示，您可以查看并创建管道。

图3-22

查看和创建管道

创建管道后，它将首次运行并执行所有已配置的阶段。如图3-23所示，配置了两个阶段(Source和Build)；管道从AWSCodeCommit获取源工件，并使用AWSCodeBuild构建它。

图3-23

成功的管道运行

我们将探讨AWS的基础设施即代码(IaC)产品，这将帮助您了解如何轻松地在AWS上自动配置资源。

AWSCloudFormation是一项允许您在模板中定义AWS资源的服务，该模板可以用jSON或YAML语言编写。在CloudFormation中，您定义您的目标架构和模板中所有不同组件的集成，然后创建一个堆栈来提供资源。

可以在AWS控制台上评估AWS云的形成，如图3-24所示。

图3-24

从AWS控制台访问CloudFormation服务

要创建CloudFormation堆栈，您必须有一个模板来定义您将供应的资源。CloudFormation具有不同的部分和必须遵守的定义的剖析，以确保当使用模板创建堆栈时，CloudFormation知道如何处理一个或多个资源的生命周期。

清单3-5中给出的模板显示了启用版本控制的S3存储桶的定义。此外，S3存储桶的名称是在运行时动态生成的，它由AWS帐号和将在其中创建堆栈的AWS区域组成，然后存储桶名称作为CloudFormation堆栈的输出进行传递。

AWSTemplateFormatVersion:'2010-09-09'Description:'SampleS3BucketwithVersioningEnabled'Resources:S3Bucket:Type:AWS::S3::BucketProperties:BucketName:!Sub${AWS::AccountId}-${AWS::Region}-bucketVersioningConfiguration:Status:EnabledDeletionPolicy:RetainOutputs:BucketName:Value:!RefS3BucketDescription:S3BucketNameListing3-5CloudFormationtemplate从搜索栏或AWS管理控制台主页访问CloudFormation控制台后，要从定义的模板创建CloudFormation堆栈，请选择创建堆栈选项，如图3-25所示。

图3-25

创建云形成堆栈

这将启动创建工作流，第一步是提供您想要启动的模板。图3-26显示了如何上传已经创作的模板。

图3-26

提供云形成模板

在提供这个模板并选择下一个的之后，CloudFormation处理模板并解析错误和无效条目。一旦模板被验证，你就可以配置栈名和参数(如果有的话)，如图3-27所示。

图3-27

配置堆栈详细信息

理想情况下，下一步也是最后一步是创建堆栈。然而，在CloudFormation中有一个称为变更集的概念，它允许您可视化和检查将对CloudFormation堆栈中的资源进行的变更，即，将被添加、删除或只是修改的资源。图3-28显示了继续创建堆栈或创建变更集的选择。

图3-28

创建变更集

如果你只是选择创建堆栈，CloudFormation就会开始创建你的资源。如果您选择创建变更集，则在创建变更集之前，将需要其他配置，如变更集名称。图3-29显示了使用变更集配置的默认值。

图3-29

配置变更集

更改集将允许您查看将要进行的配置更改的详细信息。图3-30显示只添加一个资源，一个S3存储桶。这是因为这是一个初始的栈创建，而清单3-5中的云形成模板只定义了一个S3资源。

图3-30

用于堆栈创建的更改集

如果您对更改不满意，您可以删除更改集，并且不会发生任何操作。当执行变更集时，资源创建或更新开始。图3-31显示了根据图3-30中执行的变更集创建的云形成堆栈。

图3-31

堆栈创建完成

CDK是一个作为代码框架的开源基础设施，允许您用熟悉的编程语言(如TypeScript、JavaScript、Python、Java和C#)定义AWS资源。这使得开发人员更容易将基础设施供应集成到现有的软件开发生命周期中。

当在CDK定义和部署基础设施时，CDK使用CloudFormation来部署资源，因此它负责将CDK脚本转换为相应的CloudFormation模板来部署资源。

AWSCDK工具包可以与节点程序包管理器(npm)一起安装。清单3-6显示了AWSCDK工具包的安装示例。

$sudonpminstall-gaws-cdk/usr/bin/cdk->/usr/lib/node_modules/aws-cdk/bin/cdk>aws-sdk@2.932.0postinstall/usr/lib/node_modules/aws-cdk/node_modules/aws-sdk>nodescripts/check-node-version.js+aws-cdk@1.110.0added181packagesfrom216contributorsin8.404sListing3-6AWSCDKtoolkitinstallation安装CDK之后，您可以使用命令cdk--version检查CDK版本来测试安装。

正确安装CDK后，您可以开始用任何受支持的CDK语言创建您的基础设施。在清单3-7中，我展示了如何用Python初始化一个CDK应用和一个输出片段。

$mkdirhello-cdk$cdhello-cdk$cdkinitapp--languagepythonApplyingprojecttemplateappforpython#WelcometoyourCDKPythonproject!ThisisablankprojectforPythondevelopmentwithCDK.The`cdk.json`filetellstheCDKToolkithowtoexecuteyourapp.ThisprojectissetuplikeastandardPythonproject.Theinitializationprocessalsocreatesavirtualenvwithinthisproject,storedunderthe`.venv`directory.Tocreatethevirtualenvitassumesthatthereisa`python3`(or`python`forWindows)executableinyourpathwithaccesstothe`venv`package.Ifforanyreasontheautomaticcreationofthevirtualenvfails,youcancreatethevirtualenvmanually.TomanuallycreateavirtualenvonMacOSandLinux:$python3-mvenv.venv

Listing3-7InitializeCDKApplication当一个PythonCDK项目被初始化时，它会创建一个Python虚拟环境，如清单3-7所示。它还会创建一个requirement.txt文件，您可以在其中定义应用依赖关系。我将激活Python虚拟环境并安装依赖项，如清单3-8所示。

$source.venv/bin/activate(.venv)$python-mpipinstall-rrequirements.txtListing3-8InstallingCDKprojectdependencies在CDK，基础设施是以堆栈的形式定义的，一个CDK应用必须至少包含一个堆栈，才能部署资源。当CDK将其脚本转换为CloudFormation时，它会为每个CDK堆栈创建一个CloudFormation堆栈。

当我初始化CDK应用时，创建了一个示例栈HelloCdkStack，你可以通过运行命令cdkls来查看CDK栈的列表，如清单3-9所示。

(.venv)$cdklsHelloCdkStackListing3-9CDKStackList对于部署资源的CDK，您必须用选择的编程语言定义这些资源。到目前为止，初始化的CDK应用没有做任何事情，因为没有定义任何资源。我将向您展示如何通过在以下步骤中创建S3时段来定义资源。

首先，清单3-10展示了如何从AWS构造库中安装亚马逊S3CDK包。必须首先安装将要创建的每个AWS资源的CDK包。安装CDK不会安装资源级软件包；这些必须单独安装。

(.venv)$pipinstallaws-cdk.aws-s3Listing3-10InstallingAmazonS3Package安装完所有必需的包后，您可以开始在代码中定义资源及其属性。清单3-11显示了CDK堆栈中S3资源的定义。

#hello_cdk/hello_cdk_stack.pyfromaws_cdkimportcoreascdkfromaws_cdkimportaws_s3ass3classHelloCdkStack(cdk.Stack):def__init__(self,scope:cdk.Construct,construct_id:str,**kwargs)->None:super().__init__(scope,construct_id,**kwargs)bucket=s3.Bucket(self,"MyFirstBucket",versioned=True,)Listing3-11AmazonS3CDKstack在CDK定义资源后，应用就可以部署了。在部署之前，您可以合成并查看为定义的CDK资源生成的CloudFormation模板，如清单3-12所示。

(.venv)$cdksynthResources:MyFirstBucketB8884501:Type:AWS::S3::BucketProperties:VersioningConfiguration:Status:EnabledUpdateReplacePolicy:RetainDeletionPolicy:RetainMetadata:aws:cdk:path:HelloCdkStack/MyFirstBucket/ResourceListing3-12CDKsynthoutputsnippet对于部署CDK应用，命令是cdkdeploy。示例部署见清单3-13。

(.venv)$cdkdeployHelloCdkStack:deploying...HelloCdkStack:creatingCloudFormationchangeset...HelloCdkStackStackARN:arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/HelloCdkStack/36fb9a60-d6dc-11eb-8377-0ab7c9206afbListing3-13CDKappdeployment当部署CDK应用时，它会创建一个CloudFormation堆栈，该堆栈也可以在AWS管理控制台上访问，如图3-32所示。

图3-32

已部署的CDK应用的云结构堆栈

CDKCLI也可用于删除已部署的资源。当cdk应用被删除时，底层的CloudFormation栈也被删除。清单3-14显示了在清单3-13中创建的单个CDK堆栈的删除。

(.venv)$cdkdestroyAreyousureyouwanttodelete:HelloCdkStack(y/n)yHelloCdkStack:destroying...HelloCdkStack:destroyedListing3-14DeletingCDKapp监控和记录监控是DevOps的重要组成部分。了解已部署应用的性能并记录应用活动，可以让您主动识别问题和模式，从而进一步提高软件质量。

让我们从AWSCloudWatch开始，探索可以帮助您满足应用中的日志记录和监控需求的AWS产品。

AmazonCloudWatch是用于监控和记录应用性能和活动的AWS产品。由于监控和日志记录有不同的组件，CloudWatch根据功能分为不同的子服务。图3-33显示了CloudWatch控制台。左窗格中显示了CloudWatch的不同产品。

图3-33

AWS云观察服务控制台

让我们探讨一下AWSCloudWatch的一些常见用例。

大多数AWS服务原生地将指标数据发布到CloudWatch指标。当您创建一个与CloudWatch本机集成的AWS资源时，无需额外的操作，您就可以查看该资源的指标以监视该资源的不同方面。AWS为每种资源类型提供了现成的指标支持；但是，您也可以发布自定义指标来监控CloudWatch本身不支持的组件。

可以在AWS控制台的图表中查看发布的指标，如图3-34所示。

图3-34

可用的CloudWatch指标

这是AWSCloudWatch的日志聚合功能。存储在AWSCloudWatch中的日志可以来自运行在内部或云上的应用。一些AWS服务与CloudWatch日志进行了本机集成，并在那里存储它们的日志，几乎不需要额外配置。这种服务的例子是无服务器产品，如AWSLambda，这是一种允许您在云上执行代码而无需提供资源的服务，以及AWSCodeBuild，它提供了一个编译代码、运行测试和产品工件的计算环境。

CloudWatchLogs还有一个功能CloudWatchLogsInsights，可以让您轻松查询和分析您的日志数据，以快速响应运营问题。

根据CloudWatch中的指标数据，您可以基于该数据创建警报，以便在达到特定阈值时执行操作。例如，您可以创建一个CloudWatch警报，以便在CPU利用率指标超过阈值时执行扩展操作。可以从CloudWatch日志数据事件中创建指标，因此这也提供了基于存储在CloudWatch日志中的应用日志中的事件来配置警报的能力。

您通过AWS控制台、CLI或SDK工具在AWS上执行的所有活动都是由AWSCloudTrail监控和记录的API调用。CloudTrail日志存储在亚马逊S3桶中。CloudTrail存储的信息提供了AWS帐户中活动的审计跟踪，这使得审计用户的操作或代表用户执行操作的AWS服务变得更加容易。

在这一章中，我谈到了针对持续集成、持续交付、基础设施即代码和监控的不同AWSDevOps产品。我们探讨了基本细节、它们的用例，并在AWS管理控制台上演示了这些资源的示例供应。

在下一章，我们将详细介绍在AWS上配置macOS服务器，这将为在AWS上本地开发iOS提供基础。

传统上，iOS应用开发人员必须购买硬件macOS工作站或服务器来开发iOS应用，因为这些应用只能在iOS操作系统上构建、测试和部署。这限制了开发人员将云原生解决方案集成到他们的开发过程中的能力，从而无法利用云的力量。

AmazonEC2Mac实例消除了这些限制，在这一章中，我们将深入研究部署它的不同选项，开始使用它来开发您的iOS应用。

AmazonEC2Mac释放了在云上运行按需macOS工作负载的能力，因此允许iOS开发人员受益于AWS云提供的灵活性、可扩展性、敏捷性和成本优势。

它由Macmini硬件提供支持，目前由3.2GHz英特尔第八代(咖啡湖)酷睿i7处理器提供支持。您可以使用EC2Mac实例为Apple设备(如iPhone、iPad、iPod、Mac、AppleWatch和AppleTV)开发、构建、测试和签署应用。

要连接到EC2Mac实例，您可以使用SSH进行命令终端访问，或者使用支持虚拟网络计算(VNC)协议的客户端来获得完整的用户界面(UI)体验。

因为每个EC2Mac实例都是由实际的Macmini硬件在幕后驱动的，所以默认情况下，AWS会对提供Mac实例的帐户进行限制。这是为了防止滥用并为真实用户保留容量。

在您尝试部署之前，请查看您的EC2限额，以确保您有配额为您打算使用的区域中的帐户进行部署。要检查您的配额，请从AWS管理控制台转到EC2服务，如图4-1所示。

图4-1

从AWS管理控制台访问EC2

从EC2控制台，到达如图4-2所示的极限。

图4-2

从EC2控制台访问限制页面

在那里可以搜索Mac专用主机限制，如图4-3所示。该限制表示您可以供应多少MacEC2实例。如果适用，您可以从门户网站提出限额增加请求，并提供您的使用案例。

图4-3

客户和地区的EC2Mac限额

Mac实例只能作为专用主机上的裸机实例，因为AmazonEC2Mac实例和Macmini服务器之间存在一对一的映射。您可以为每个专用主机启动一个Mac实例，并且可以与AWS组织内的AWS帐户或组织单位或整个AWS组织共享该专用主机。

EC2Mac实例不符合免费层的条件，按分配的专用主机计费，而不是按实例计费，专用主机在您可以释放之前有24小时的最短分配期。

像大多数AWS服务一样，您可以使用各种选项来提供EC2Mac实例。在这一节中，我将通过创建和提供示例代码向您展示可用的主要选项。

AWS管理控制台是开始提供AWS服务的最简单方法。要配置EC2Mac服务器，首先要配置一台专用主机。参见图4-4了解如何从EC2控制台访问专用主机。

图4-4

从EC2控制台访问专用主机

在专用主机控制台上，选择选项开始分配，如图4-5所示。

图4-5

开始分配专用主机

如图4-6所示填写分配参数，分配专用主机。主要参数字段描述如下:

图4-6

专用主机设置

在分配之后，它可以立即在其上启动一个实例。图4-7显示了如何在专用主机上启动EC2Mac实例的供应。

图4-7

在专用主机上启动Mac实例

此操作将启动EC2实例创建过程。如图4-8所示，您选择macOSAmazon机器映像(AMI)用于启动MacEC2实例。

图4-8

为实例启动选择macOSAmazon机器映像(AMI)

下一步是选择实例类型。非灰色选项是所选AMI的可用实例类型。在图4-9中，已经选择了mac1.metal实例类型。

图4-9

选择macOS实例类型

实例细节可以如图4-10所示进行配置。在这里，您可以配置VPC、子网、主机配置等。

图4-10

配置EC2Mac详细信息

对于实例存储，现在可以配置默认存储，如图4-11所示。默认存储足以进行初始部署和连接。

图4-11

默认Mac实例存储

为了在启动后允许入站网络连接到Mac实例，定义了安全组规则，以允许从特定IP连接到适用的端口。如图4-12所示，允许从我的IP地址到TCP端口22(安全外壳(SSH)协议端口)和TCP端口5900(虚拟网络计算(VNC)协议端口)的连接。

图4-12

为入站连接配置安全组规则

配置安全组规则后，检查输入的所有配置详细信息的准确性，并继续启动实例。

此外，对于到Mac实例的入站用户SSH连接，需要EC2密钥对。您可以使用您在帐户中创建的现有密钥对，也可以创建一个新的密钥对。图4-13显示了在启动实例之前创建新密钥对的过程。

图4-13

在启动实例之前创建新的EC2密钥对

实例一旦启动，就会出现在专用主机下的运行实例选项卡下，如图4-14所示。

图4-14

运行实例的专用主机

您还可以通过选择实例来查看有关运行实例的更多详细信息。这会将您重定向到EC2实例控制台，如图4-15所示。

图4-15

MacEC2实例详细信息

EC2Mac实例也可以从AWS命令行界面(CLI)提供。要使用AWSCLI，必须先将其安装在工作站上，并使用适当的身份访问管理(IAM)凭据配置工作站。

要提供EC2Mac实例，首先要分配一个专用主机，如清单4-1所示。

awsec2allocate-hosts--regionus-east-1--instance-typemac1.metal--availability-zoneus-east-1c--auto-placement"on"--quantity1Listing4-1Allocatingdedicatedhost一旦分配了专用主机，就可以创建一个Mac实例，如清单4-2所示。您将获得一个包含实例ID的响应，该实例ID可用于后续的CLI命令。

awsec2run-instances--regionus-east-1--instance-typemac1.metal--placementTenancy=host--image-idami-059ff882c04ebed21--key-namemy-key-pairListing4-2ProvisioningEC2Macinstanceonthededicatedhost通过描述清单4-3中所示的状态来验证创建的实例。使用在创建过程中从CLI响应中检索到的实例ID。

awsec2describe-instance-status--instance-idsListing4-3VerifyingInstancecreationstatus使用AWSCloudFormation部署AWSCloudFormation是一个基础设施即代码服务，它允许您对要在jSON或YAML模板中部署的资源进行建模。然后，该模板被传递给AWSCloudFormation，以提供定义的资源。

要使用CloudFormation部署EC2Mac实例，您将定义模板中所需的所有组件，如清单4-4所示。

如清单4-4所示，模板中定义的两个资源是EC2Mac安全组和Mac实例。要启动CloudFormation模板，从AWSCloudFormation控制台创建一个栈，选择文件，点击next，如图4-16所示。

图4-16

选择EC2MacCloudformation模板以创建堆栈

接下来，您将输入模板中定义的用户参数，如图4-17所示。有些示例值已经作为默认值输入，应该用特定于您的环境和AWS帐户的信息覆盖这些值。

图4-17

输入云形成堆栈参数

要在创建之前检查将要创建的资源，您可以创建一个变更集。改变设置如图4-18所示。

图4-18

EC2Mac创建的云信息更改集

清单4-5显示了terraformHCL模板中EC2Mac资源的定义。

要使用Terraform，必须在工作站上安装软件，并且必须配置目标AWS帐户的身份访问管理(IAM)凭据。

部署Terraform中定义的资源。tf文件，初始化您的工作目录，如清单4-6所示，使其成为Terraform工作目录，并安装所有的依赖项。

terraform>terraforminitInitializingthebackend...Initializingproviderplugins...-Findinglatestversionofhashicorp/aws...-Installinghashicorp/awsv3.49.0...-Installedhashicorp/awsv3.49.0(signedbyHashiCorp)Listing4-6InitializingTerraform在尝试部署以修复任何语法问题之前，您还可以验证您的Terraform文件，如清单4-7所示。

terraform>terraformvalidateSuccess!Theconfigurationisvalid.Listing4-7ValidatingTerraformfilesindirectory要预览像CloudFormation变更集一样将被提供的所有资源，您可以执行一个terraformplan命令。这向您显示了有关要调配的资源及其关系的详细信息。清单4-8显示了这个命令的输出片段。

terraform>terraformplanTerraformusedtheselectedproviderstogeneratethefollowingexecutionplan.Resourceactionsareindicatedwiththefollowingsymbols:+createTerraformwillperformthefollowingactions:#aws_instance.ec2-mac-instancewillbecreated+resource"aws_instance""ec2-mac-instance"{+ami="ami-059ff882c04ebed21"+arn=(knownafterapply)+associate_public_ip_address=(knownafterapply)....Plan:2toadd,0tochange,0todestroy.-----------------------------------------------------------------------------------------------Note:Youdidn'tusethe-outoptiontosavethisplan,soTerraformcan'tguaranteetotakeexactlytheseactionsifyourun"terraformapply"now.Listing4-8ViewingTerrformplanbeforeresourcecreation在查看了所有要创建的资源之后，要开始创建，您需要应用清单4-9中所示的配置。

terraform>terraformapplyListing4-9Applyingterraformconfiguration现在我已经展示了如何部署EC2Mac服务器，接下来我们将探索如何连接到它。

使用SSH连接后，可以配置密码验证，以允许使用虚拟网络计算(VNC)客户端进行连接。

为了使用SSH进行连接，本节讨论了各种选项，以适应您的操作系统和/或偏好。

在Windows和Linux操作系统上，最常见的连接方法是通过命令终端并使用内置的SSH客户端。清单4-10中的示例显示了使用命令终端的SSH命令。

ssh-i/path/my-key-pair.pemec2-user@ec2-12-23-45-67.compute-1.amazonaws.comListing4-10SSHoncommandterminal窗户油灰Putty是一个用于windows的免费开源telnet和SSH客户端，也可用于连接EC2Mac实例。要使用Putty，您必须将。pem密钥对与.ppk密钥的兼容性。转换后，您提供。ppk键如图4-19所示。

图4-19

为Putty会话提供身份验证

配置好身份验证后，按照格式ec2-user@<主机名>指定主机名以及端口和连接类型，如图4-20所示。

图4-20

正在启动PuttySSH会话

图4-21

EC2Mac服务器的命令终端

要连接到Mac服务器的用户界面(UI),您必须使用VNC客户端。但是在使用VNC客户端之前，有几个先决条件需要配置。

默认情况下，ec2用户禁用密码验证。要使用VNC客户端并连接到UI，必须为ec2用户创建密码，如清单4-11所示。

要在Mac服务器上启用远程桌面连接，必须从Mac服务器的终端启动苹果远程桌面代理，如清单4-12所示。

ec2-user@ip-172-31-47-239~%sudo/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart\-activate-configure-access-on\-restart-agent-privs-allStarting...Warning:macos10.14andlateronlyallowscontrolifScreenSharingisenabledthroughSystemPreferences.ActivatedRemoteManagement.StoppedARDAgent.ec2-user:Setuserremotecontrolprivileges.ec2-user:Setuserremoteaccess.Done.Listing4-12StartingAppleRemoteDesktopAgent设置SSH端口转发您可以从工作站上的VNC客户端直接连接到端口5900(VNC端口)上的Mac服务器的IP地址，但是VNC协议被认为是不安全的。一种更安全的方法是从您的工作站使用SSH端口转发功能通过SSH隧道传输VNC流量。

清单4-13展示了如何将本地主机端口5900的所有流量转发到EC2Mac服务器端口5900。因此，要连接到Mac服务器，您需要向本地主机端口5900发送流量。

ssh-L5900:localhost:5900-i/path/my-key-pair.pemec2-user@your-instance-public-dns-nameListing4-13SSHtunnelingVNCtraffic下载VNC客户端并连接根据您的操作系统，有多种VNC客户端选项可供使用。一个这样的选项是VNC浏览器，它可以跨多个操作系统使用；可以下载，如图4-22所示。

图4-22

下载VNC客户端

它可以安装在Windows操作系统上，如图4-23所示。

图4-23

在Windows上安装VNC客户端

安装完成后，确保按照清单4-13中的描述设置了端口5900SSH隧道，然后可以通过连接到本地主机开始连接Mac服务器，如图4-24所示。

图4-24

使用VNC客户端连接到EC2Mac服务器

图4-25

图4-26

EC2Mac服务器主屏幕

默认情况下，EC2Mac实例会向AmazonCloudWatch发出指标以进行性能监控。它发送CPU利用率、网络使用信息等指标。EC2Mac实例的指标可以在EC2控制台上查看，方法是在实例上选择，然后转到Monitoring选项卡。这方面的一个例子如图4-27所示。

图4-27

EC2控制台上的实例度量信息

这些指标也可以在亚马逊CloudWatch控制台上查看。CloudWatch控制台为您提供了更多的图表选项，并允许您在同一个图表上比较多个指标，如图4-28所示。

图4-28

Cloudwatch上的实例度量图

要禁用向CloudWatch发送CPU利用率等系统监控指标的代理，可以运行清单4-14中所示的设置。

$sudosetup-ec2monitoring[enable|disable]Listing4-14ConfiguringEC2systemmonitoringforMacinstance清理AmazonEC2Mac服务器如果不经常使用AmazonEC2服务器，要清理它，首先要终止EC2实例，然后释放专用主机。

要终止实例，从EC2仪表板中，选择实例并选择您想要终止的mac1.metal实例。选择实例状态，然后选择终止实例。

由于AmazonEC2Mac实例不是按实例收费的，而是由专用主机收费的，终止实例并不能停止收费，必须释放专用主机才能停止收费。

要释放主机，从EC2仪表板中，选择专用主机并选择您想要释放的专用主机。选择动作，然后选择发布主机。

我们讨论了部署EC2macOS实例的细节，探索了不同的部署方法。我还向您展示了不同的连接选项，同时还介绍了连接EC2Mac服务器的先决条件。

在下一章中，我们将在此基础上进行构建，我将向您展示如何在EC2macOS实例上安装和设置各种iOS开发和构建工具。

要在AmazonEC2Mac实例上开始开发，就像任何其他Mac构建服务器一样，必须安装Xcode等iOS构建工具。还有其他开源和第三方自动化工具，如Jenkins，Fastlane等。，它与Xcode集成以增加自动化并改进iOS开发流程。

在本章中，我们将探讨如何在亚马逊EC2macOS实例上安装Xcode、Jenkins、Fastlane和GitLabRunner。但是，在安装软件之前，必须有足够的存储空间，因此我们将从如何增加macOS实例的卷大小开始。

要安装像Xcode这样的iOS应用构建工具，必须有足够的磁盘空间。macOS实例卷大小可以在启动时或Mac实例运行后修改。如果在启动时没有修改卷大小，AmazonEC2Mac实例提供的默认磁盘大小可能不够。

macOS实例使用Amazon弹性块存储(EBS)卷。增加正在运行的macOS实例的存储容量包括增加所连接的EBS卷的容量、重新启动实例，以及使增加的磁盘空间可供使用。

在EC2控制台上选择macOS实例，可以看到实例卷大小，如图5-1所示。要增加卷大小，点击EBS卷ID，如图5-1所示；这将引导您进入EBS控制台。

图5-1

macOS实例详细信息中显示的卷大小

进入卷修改页面，如图5-2所示。

图5-2

选择修改卷选项

修改实例EBS卷大小。图5-3中所示的示例将卷增加到200GB。

图5-3

将音量调整到所需的大小

调整正在运行的macOS实例的附加EBS卷的大小后，在重新启动之前，该卷在实例中不可见。您可以从EC2控制台重启macOS实例，如图5-4和5-5所示。

图5-5

确认实例重新启动

图5-4

调整宗卷大小后重新启动macOS实例

在调整EBS卷大小时，macOS重新启动后，新的磁盘大小应该在macOS实例上可见，如清单5-1所示。

ec2-user@ip-172-31-47-239~%diskutillistexternalphysical/dev/disk1(external,physical):#:TYPENAMESIZEIDENTIFIER0:GUID_partition_scheme*214.7GBdisk11:EFIEFI209.7MBdisk1s12:Apple_APFSContainerdisk264.2GBdisk1s2Listing5-1Listingdisksize如清单5-1所示，新的磁盘大小是可见的，但是APFS容器的大小仍然较小，因此增加的磁盘空间还没有被使用。增加的磁盘大小可以变得可用，如清单5-2所示。

ec2-user@ip-172-31-47-239~%PDISK=$(diskutillistphysicalexternal|head-n1|cut-d""-f1)ec2-user@ip-172-31-47-239~%APFSCONT=$(diskutillistphysicalexternal|grep"Apple_APFS"|tr-s""|cut-d""-f8)ec2-user@ip-172-31-47-239~%yes|sudodiskutilrepairDisk$PDISKRepairingthepartitionmapmighterasedisk1s1,proceed(y/N)Startedpartitionmaprepairondisk1CheckingprerequisitesListing5-2Repairingdiskandmakingincreasedsizeusable修复之后，最后一步是调整苹果APFS容器的大小，如清单5-3所示。

ec2-user@ip-172-31-47-239~%sudodiskutilapfsresizeContainer$APFSCONT0StartedAPFSoperationAligninggrowdeltato150,323,855,360bytesandtargetinganewphysicalstoresizeof214,538,608,640bytesDeterminedthemaximumsizeforthetargetedphysicalstoreofthisAPFSContainertobe214,537,580,544bytesListing5-3ResizingAPFScontainersize设置XcodeXcode可以从AppStore手动安装在macOS实例上，正如第一章所讨论的。安装Xcode后，要开始使用Xcode，您必须接受Xcode和iOSSDK许可协议，如图5-6所示。

图5-6

Xcode和iOSSDK许可协议

如果提示输入密码以授予Xcode权限，请输入您的用户密码。如果使用默认的ec2用户，这是为用户创建的用户密码，如第四章所述。

一旦Xcode准备好使用，它应该会进入它的欢迎页面，如图5-7所示。

图5-7

Xcode欢迎页面

从AppStore安装Xcode时，它的命令行工具也会被安装，无需任何进一步操作。可以从命令终端验证安装，如清单5-4所示。

ec2-user@ip-172-31-47-239~%xcode-select--installxcode-select:error:commandlinetoolsarealreadyinstalled,use"SoftwareUpdate"toinstallupdatesec2-user@ip-172-31-47-239~%xcodebuildCommandlineinvocation:/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuildUserdefaultsfromcommandline:IDEPackageSupportUseBuiltinSCM=YESxcodebuild:error:Thedirectory/Users/ec2-userdoesnotcontainanXcodeproject.ec2-user@ip-172-31-47-239~%xcodebuild-versionXcode12.5.1Buildversion12E507Listing5-4VerifyingXcodecommandlinetoolsinstallation陷害JenkinsJenkins是一个开源的自动化和应用构建工具。它与各种其他工具相集成，这使得它适用于各种类型的构建和自动化。Jenkins支持分布式构建；通过使用并行运行作业的代理，可以为每个生成项目使用不同的生成环境。

这些代理由控制器控制，控制器是配置和调度所有构建作业的主要Jenkins节点。代理可以是与控制器相同类型的环境，在控制器中调度作业以平衡工作负载，也可以是与主控制器不同的环境，在主控制器中，基于正在构建的应用所需的构建环境在代理上调度作业。

让我们在接下来的两节中探索如何在AmazonEC2实例上的Linux环境中配置Jenkins控制器，以及如何使用macOS构建代理来构建iOS应用。

控制器将在AmazonEC2Linux实例上提供，因此，首先，必须从EC2控制台创建一个EC2实例，如图5-8所示。

图5-8

从EC2控制台启动AmazonEC2实例

选择适用AWS地区的最新AmazonLinuxAmazonMachineImage(AMI)，如图5-9所示。

图5-9

选择最新的亚马逊LinuxAMI

选择实例类型，并根据需要配置实例和存储容量。对于安全组，需要SSH(TCP端口22)访问来启用对Jenkins服务器的访问。Jenkins还在TCP端口8080上提供流量，因此这必须在安全组中得到允许。安全组配置示例如图5-10所示。这些规则可以通过工作站的源IP地址进一步限制。

图5-10

配置安全组规则

因为提供了AmazonLinuxEC2实例，所以将使用yumpackagemanager来安装Jenkins。类似地，其他操作系统中的包管理器可以用来在那些操作系统上安装Jenkins。

首先，执行实例上所有包的快速软件更新，如清单5-5所示。

[ec2-user~]$sudoyumupdateListing5-5Updatingsoftwarepackages更新软件包后，可以将Jenkinsrepo添加到yum中，如清单5-6所示。

[ec2-user~]$sudoyuminstalljenkinsjava-1.8.0-openjdk-devel-y[ec2-user~]$sudosystemctldaemon-reloadListing5-8InstallingJenkins安装后，Jenkins可以作为服务启动，如清单5-9所示。

[ec2-user~]$sudosystemctlstartjenkinsListing5-9StartingJenkinsasaservice如清单5-10所示，可以检查Jenkins状态。

[ec2-user~]$sudosystemctlstatusjenkinsListing5-10CheckingJenkinsstatus最初设置Jenkins时，需要一个初始管理员密码。如清单5-11所示，可以检索该密码。

图5-11

Jenkins初始设置页面

为了支持不同类型的应用和工具，Jenkins使用插件来扩展其功能。在Jenkins初始设置期间，您可以选择安装特定的插件，或者安装建议的插件，如图5-12所示。

图5-12

安装Jenkins插件

还必须创建一个初始的管理员用户来验证Jenkins。初始管理员用户的设置如图5-13所示。

图5-13

创建初始管理员用户

在安装了所有插件并设置了初始管理员用户之后，Jenkins就可以开始创建作业和注册构建代理了。全新的Jenkins安装欢迎页面如图5-14所示。

图5-14

Jenkins欢迎页面

创建Jenkins控制器后，您可以为分布式生成设置生成代理。要构建iOS应用，必须存在macOS构建代理。让我们探索如何通过SSH将EC2Mac实例作为构建代理添加到Jenkins控制器中。

要添加Jenkins构建代理，必须安装Java。清单5-12展示了如何在EC2Mac上安装带有Homebrew的Java开发工具包。

sh-3.2#ln-sfn/usr/local/opt/openjdk@8/libexec/openjdk.jdk/Library/Java/JavaVirtualMachines/openjdk-8.jdksh-3.2#java-versionopenjdkversion"1.8.0_282"OpenJDKRuntimeEnvironment(build1.8.0_282-bre_2021_01_20_16_06-b00)OpenJDK64-BitServerVM(build25.282-b00,mixedmode)Listing5-13CreatesymlinkforOpenJDKandverifyInstallation安装Java之后，下一个需求是创建一个Jenkins用户并为该用户设置SSH访问。Jenkins控制器将使用该用户通过SSH连接到macOS构建代理，以提交构建作业。您可以创建一个新的Jenkins用户，如清单5-14所示。

sh-3.2#sysadminctl-addUserjenkins2021-07-1019:50:42.793sysadminctl[6437:155160]--------------2021-07-1019:50:42.793sysadminctl[6437:155160]Nocleartextpasswordorinteractiveoptionwasspecified(adduser,change/resetpasswordwillnotallowusertouseFDE)!2021-07-1019:50:42.793sysadminctl[6437:155160]--------------2021-07-1019:50:42.970sysadminctl[6437:155160]Creatinguserrecord...2021-07-1019:50:43.043sysadminctl[6437:155160]AssigningUID:503GID:202021-07-1019:50:43.076sysadminctl[6437:155160]Creatinghomedirectoryat/Users/jenkinsListing5-14CreatingJenkinsuser创建用户后，您可以设置一个新的密钥，或者在macOS实例上重用现有的默认ec2-user密钥。清单5-15展示了如何对新的Jenkins用户重用默认的ec2用户SSH凭证。

sh-3.2#mkdir/Users/jenkins/.ssh/sh-3.2#cp-a/Users/ec2-user/.ssh/./Users/jenkins/.ssh/sh-3.2#cp/Users/ec2-user/.ssh/*/Users/jenkins/.ssh/.sh-3.2#chown-Rjenkins/Users/jenkins/.sshsh-3.2#chmod700/Users/jenkins/.sshsh-3.2#chmod600/Users/jenkins/.ssh/authorized_keysListing5-15SettingupSSHkeysforJenkinsuser接下来，让我们确保Jenkins控制器可以通过SSH从安全组访问EC2Mac实例。

如图5-15所示，为Jenkins控制器实例的/32私有IP地址配置TCP端口22访问。使用私有IP地址是因为Jenkins控制器和EC2Mac实例位于同一个虚拟私有云(VPC)中。如果它们在不同的VPC中，并且Jenkins控制器将通过互联网与Mac实例连接，您将添加Jenkins控制器的公共IP地址。

图5-15

EC2Mac实例的安全组配置

安装了Java、创建了Jenkins用户、设置了SSH访问并配置了安全组之后，就可以添加EC2macOS实例作为构建节点了。

在Jenkins用户界面上，选择“管理Jenkins”选项，然后选择“管理节点和云”，如图5-16所示。

图5-16

管理Jenkins选项

启动添加新节点的流程，并为节点提供名称，如图5-17所示。

图5-17

添加新的Jenkins节点

将配置节点的连接信息，包括节点的IP地址、启动方法、标签、节点的凭证等。该标签是在生成作业中配置的，控制器使用它来标识要在其上调度特定作业的生成代理。图5-18显示了使用SSH启动方法和iOS标签的节点配置示例。

SSH凭证必须单独配置。凭据可以预先创建，也可以在添加节点时创建。图5-18显示了如何在配置构建节点时添加新凭证。

图5-18

为Jenkins节点配置新凭据

要添加SSH凭证，您需要提供Jenkins用户名和SSH私有密钥。要获取私钥内容，请打开为Jenkins用户SSH访问配置的私钥文件。

图5-19显示了配置SSH凭证的示例。

图5-19

在Jenkins中配置SSH凭证

可以为节点配置路径变量等环境变量，如图5-20所示。

图5-20

为节点配置环境变量

保存新节点的配置。在图5-18中，主机密钥验证被配置为手动信任，因此在保存新节点配置后，Jenkins控制器尝试通过SSH连接到构建代理，并且在Jenkins节点的左侧选项中显示提示，请求信任Jenkins控制器；选择此项以允许继续连接。

您可以在Jenkins上查看控制台输出，以查看状态并了解它的运行情况。列表5-16显示了一个成功添加代理的控制台输出示例。

[07/11/2117:31:16][SSH]Checkingjavaversionofjava[07/11/2117:31:16][SSH]java-versionreturned1.8.0_282.[07/11/2117:31:16][SSH]Startingsftpclient.[07/11/2117:31:16][SSH]Copyinglatestremoting.jar...[07/11/2117:31:16][SSH]Copied1,502,119bytes.Expandedthechannelwindowsizeto4MB[07/11/2117:31:16][SSH]Startingagentprocess:cd"/Users/Jenkins"&&java-jarremoting.jar-workDir/Users/Jenkins-jar-cache/Users/Jenkins/remoting/jarCacheJul11,20215:31:17PMorg.jenkinsci.remoting.engine.WorkDirManagerinitializeWorkDirINFO:Using/Users/Jenkins/remotingasaremotingworkdirectoryJul11,20215:31:17PMorg.jenkinsci.remoting.engine.WorkDirManagersetupLoggingINFO:Botherrorandoutputlogswillbeprintedto/Users/Jenkins/remoting<===[JENKINSREMOTINGCAPACITY]===>channelstartedRemotingversion:4.7ThisisaUnixagentEvacuatedstdoutAgentsuccessfullyconnectedandonlineListing5-16OutputsnippetofaddingJenkinsagent添加一个构建节点后，它会出现在节点列表中，如图5-21所示。

图5-21

Jenkins建立节点

Fastlane是一个开源自动化工具，用于自动化移动应用开发。它自动化了构建iOS应用的所有方面，从开发到发布到应用商店。其主要特点是

Fastlane可以与Jenkins集成，为iOS应用开发创建完整的端到端持续集成持续交付(CICD)流程。

Fastlane可以使用自制软件简单地安装在macOS工作站上，如清单5-17所示。

ec2-user@ip-172-31-47-239~%brewinstallfastlaneUpdatingHomebrew...==>Auto-updatedHomebrew!Updated2taps(homebrew/coreandhomebrew/cask).==>UpdatedFormulaeUpdated52formulae.==>UpdatedCasksUpdated13casks......==>Installingfastlane==>Pouringfastlane--2.187.0.big_sur.bottle.1.tar.gzListing5-17Fastlaneinstallationoutputsnippet安装后，您可以验证安装并开始使用Fastlane。清单5-18中显示了启动Fastlane的示例和输出示例。

清单5-18。从Fastlane出发

GitLab是一个DevOps平台，它提供了许多特性来提高软件开发过程中的灵活性。其中的一些特性包括用于管理源代码的gitrepositorymanager、持续集成以及用于自动构建和部署应用的部署管道等。

对于其持续集成和部署特性，它使用GitLabrunner。GitLabRunner是一个与GitLabCICD协同工作的应用，用于在管道中运行作业。GitLabRunner应用可以安装在单独的基础设施和操作系统上，这取决于Runner将要执行的工作。

图5-22

创建GitLab项目

接下来，您可以选择如何创建项目，如图5-23所示，您可以创建一个空白项目或使用一个模板，该模板会用文件预先填充您的项目。

图5-23

选择项目初始配置

配置项目名称、URL和可见性级别(私有或公共)。图5-24显示了一个示例项目配置。

图5-24

配置和创建GitLab项目

当您创建GitLab项目时，会为项目创建一个存储库，您可以访问许多DevOps特性，其中包括CICD。要设置可以构建iOS应用的GitLabCICD管道，必须设置一个macOSGitLab运行程序。

项目的GitLabRunner配置可以在项目设置中进入，如图5-25所示。

图5-25

GitLab项目CICD设置

要在macOS实例上注册GitLabrunner，需要GitLab位置的URL和唯一的注册令牌。在项目CICD设置中展开滑道即可找回两者，如图5-26所示。

图5-26

GitLabRunner注册令牌和URL

GitLabRunner以二进制形式提供。您可以下载二进制文件并在macOS实例上提供适当的权限，如清单5-19所示。

ec2-user@ip-172-31-47-239~%gitlab-runnerinstallRuntimeplatformarch=amd64os=darwinpid=4237revision=c1edb478version=14.0.1ec2-user@ip-172-31-47-239~%gitlab-runnerstartRuntimeplatformarch=amd64os=darwinpid=4240revision=c1edb478version=14.0.1Listing5-21InstallingandstartingGitLabRunner一旦安装了GitLabRunner，您就可以开始从GitLabCICD管道向这个Runner调度作业。要验证runner是否已注册到您的GitLab项目并准备好接收作业，请确保您可以在GitLab项目的runner列表中看到注册的macOSrunner。图5-27显示了在GitLab上注册为runner的macOS实例。

图5-27

在GitLab上查看注册的macOSrunner

设置iOS应用开发环境需要安装不同的软件，如iOS专用的Xcode和其他第三方及开源工具。我们已经介绍了在macOSAmazonEC2实例上安装和设置所有这些工具，以便为开发做好准备。

正如第三章所讨论的，AWSCodeCommit是一个托管的私有Git库。当交互和使用CodeCommit时，您使用标准的Git工具，所有标准的Git概念和特性都适用。

在本章中，我们将深入探讨如何使用AWSCodeCommit进行源代码管理，首先是如何连接到CodeCommit存储库以添加源代码，以及诸如拉请求、分支等功能是如何实现的。，工作。

在开始使用AWSCodeCommit之前，让我们回顾一下基本的Git基础知识。

所有主要平台的Git客户端都可以从Git网站下载，如图6-1所示。

图6-1

Git客户端下载

对于不同的操作系统，可以使用软件包管理器从命令行下载它。清单6-1分别展示了如何为macOS和Debian/Ubuntu系统安装Git。

macOS$brewinstallgitDebian/Ubuntu$apt-getinstallgitListing6-1Gitinstallationwithpackagemanagers初始化Git存储库一旦安装了Git，要在目录中启用Git，必须对它进行初始化。在一个目录中初始化Git意味着您希望它启动版本控制并开始跟踪该目录中的所有更改。Git可以在目录中初始化，如清单6-2所示。

$gitinitInitializedemptyGitrepositoryin/home/cloudshell-user/git-diretory/.git/$gitstatusOnbranchmasterNocommitsyetnothingtocommit(create/copyfilesanduse"gitadd"totrack)Listing6-2InitializingGitrepositoryandcheckingGitstatus记录对Git存储库的更改如清单6-2所示，在Git初始化的目录中没有Git要跟踪的文件，因为它是一个空目录。新文件被添加到目录中，如清单6-3所示。

$touchfile1file2file3$gitstatusOnbranchmasterNocommitsyetUntrackedfiles:(use"gitadd..."toincludeinwhatwillbecommitted)file1file2file3nothingaddedtocommitbutuntrackedfilespresent(use"gitadd"totrack)Listing6-3AddingnewfilesandcheckingGitstatus文件被添加到目录中，但不是为了Git开始跟踪而添加的。为了让Git开始跟踪这些新文件，首先应该如清单6-4所示进行修改。

$gitconfig--globaluser.name"EnterYourName"$gitconfig--globaluser.email"EnterYourEmail"$gitcommit-m"Addfiles"[master(root-commit)6ebb411]Addfiles3fileschanged,0insertions(+),0deletions(-)createmode100644file1createmode100644file2createmode100644file3$gitstatusOnbranchmasternothingtocommit,workingtreecleanListing6-5CommittingchangesandcheckingGitstatus克隆和使用远程Git存储库有时，您已经有一个现有的项目存储在一个远程Git存储库中，如GitHub、GitLab、AWSCodeCommit等。，你想在本地工作。为此，您可以通过克隆来本地下载存储库。在本地克隆了存储库之后，您可以对文件进行更改，并通过前面描述的Git生命周期来开始跟踪您的更改。

清单6-6显示了一个克隆存储库的例子。在这里，我克隆了公共AWSCLIGitHub存储库。要克隆您拥有的私有存储库，系统会提示您进行身份验证。

清单6-7展示了如何查看为本地存储库配置的远程存储库，如何通过拉和推操作来保持本地和远程存储库同步，以及如何为本地存储库配置不同名称的其他远程存储库。Git为远程存储库使用的默认简称是origin，并且配置了一个新的远程存储库origin2，如清单6-7所示。

在新的Git存储库中，当您创建第一个提交时，会为您创建一个默认分支。可以创建附加分支来跟踪项目的不同版本。

拉请求允许您和存储库中的其他用户从一个分支到另一个分支查看、添加注释和合并代码更改。Pullrequests是多个存储库用户协作的一种方式，在应用的新版本发布之前，通过检查代码更改和修复bug来实现。

一个典型的例子是，当您有一个主Git分支，其中包含您的应用的生产部署版本，而新功能是在单独的功能分支中开发的。当功能分支中的功能准备好进行生产部署时，拉请求允许团队成员在将功能分支合并到主分支之前检查新功能的代码更改或添加。

在第三章中，介绍了AWSCodeCommit，我介绍了如何在AWS管理控制台上创建CodeCommit存储库。在本章中，我们将更深入地了解创建CodeCommit存储库的各种方法，如AWS命令行界面(CLI)、CloudFormation、Terraform和AWSSDK。

必须首先安装和配置AWSCLI。要开始使用AWSCLI，必须使用有权执行预期操作的凭据进行配置。清单6-8展示了如何配置AWSCLI和一个示例输出。

$awsconfigureAWSAccessKeyID[None]:AWSSecretAccessKey[None]:Defaultregionname[None]:Defaultoutputformat[None]:Listing6-8ConfiguringAWSCLI配置AWSCLI环境后，可以创建一个带有示例输出的CodeCommit存储库，如清单6-9所示。

AWSTemplateFormatVersion:"2010-09-09"Parameters:RepositoryName:Type:StringDefault:devops-ios-repositoryDescription:NameoftheCodeCommitRepositoryResources:MyRepo:Type:AWS::CodeCommit::RepositoryProperties:RepositoryName:!RefRepositoryNameRepositoryDescription:ExampleDescriptionListing6-10CloudFormationtemplatetocreateCodeCommitrepository如清单所示，CloudFormation模板是YAML格式的，只包含一个CodeCommit资源。可以用这些YAML内容创建云形成堆栈，如图6-2所示。

图6-2

使用CloudFormation创建CodeCommit知识库

存储库名称是参数化的，如清单6-10所示；默认名称在模板中定义，但可以修改。该参数可以在堆栈详情页面进行修改，如图6-3所示。

图6-3

配置代码提交存储库的名称

图6-4显示了处于CREATE_COMPLETE状态的CloudFormation堆栈，这表示CodeCommit存储库已经创建。resources选项卡显示了由CloudFormation堆栈创建的资源列表。

图6-4

CodeCommit云信息堆栈已创建

在CodeCommit控制台中可以看到创建的CodeCommit存储库，如图6-5所示。

图6-5

代码提交存储库已创建

必须首先参考Terraform官方文档安装和配置Terraform。用于CodeCommit存储库创建的Terraform代码可以如清单6-11所示进行定义。

provider"aws"{region="us-east-1"}resource"aws_codecommit_repository""test"{repository_name="devops-ios-repository"description="ExampleDescription"}Listing6-11TerraformcodetocreateCodeCommitrepository代码应该保存在一个带有。tf文件扩展名，并保存在专用的Terraform目录中，以用于预期的操作。在专用目录中，可以初始化Terraform，如清单6-12所示。这里显示的操作下载了Terraform脚本中定义的资源所需的所有插件。

$terraforminitInitializingthebackend...Initializingproviderplugins...-Findinglatestversionofhashicorp/aws...-Installinghashicorp/awsv3.54.0...-Installedhashicorp/awsv3.54.0(signedbyHashiCorp)Terraformhascreatedalockfile.terraform.lock.hcltorecordtheproviderselectionsitmadeabove.IncludethisfileinyourversioncontrolrepositorysothatTerraformcanguaranteetomakethesameselectionsbydefaultwhenyourun"terraforminit"inthefuture.Terraformhasbeensuccessfullyinitialized!......................................................Listing6-12InitializingTerraformdirectory您可以选择性地运行清单6-13中所示的terraformplan来查看Terraform将在您的AWS帐户中执行的操作，即创建、删除或修改资源。

在安装boto3之前，您的工作站上需要Python。假设安装了Python，清单6-15展示了如何使用pip在工作站上安装boto3。

$pipinstallboto3Listing6-15Installingboto3清单6-16中显示了一个使用boto3创建CodeCommit存储库的示例Python脚本。

importboto3client=boto3.client('codecommit')response=client.create_repository(repositoryName='devops-ios-repository',repositoryDescription='ExampleDescription')print(responseListing6-16PythonscripttocreateCodeCommitrepository在boto3可以创建资源之前，工作站必须配置有AWS凭证。可以用AWSCLI配置凭证，如清单6-8所示。

一旦工作站配置了AWS凭证，就可以执行Python脚本，如清单6-17所示。

让我们探索连接到CodeCommit存储库和存储源代码的不同选项。

有各种选项可用于连接到CodeCommit存储库。适合您的选项将取决于您使用AWS服务的身份验证方式。例如，它是否是IAM用户、IAM角色、联合访问等。？

对于连接到CodeCommit存储库的每种方法，使用的URL是不同的；对于特定的存储库，可以检索每个连接方法的URL，如图6-6所示。

图6-6

CodeCommit连接URL

HTTPS方法用于IAM用户，它涉及为该IAM用户生成Git用户名和密码。生成的用户名和密码在执行Git操作时用作Git凭证。

要为IAM用户生成Git用户名和密码，请转到IAM用户的安全凭证设置，如图6-7所示。

图6-7

IAM用户的安全凭据设置

在IAM用户的安全凭证页面中，可以看到为AWSCodeCommit生成HTTPSGit凭证的选项，如图6-8所示。

图6-8

正在生成HTTPSGit凭据

生成凭证后，您可以下载.csv文件形式的凭证或复制用户名和密码，如图6-9所示。

图6-9

正在下载生成的HTTPS凭据

通过克隆一个新创建的存储库，生成的凭证可以用来连接到一个带有HTTPSURL的CodeCommit存储库，如清单6-18所示。

$ssh-keygenGeneratingpublic/privatersakeypair.Enterfileinwhichtosavethekey(/home/cloudshell-user/.ssh/id_rsa):/home/cloudshell-user/.ssh/codecommit_keyCreateddirectory'/home/cloudshell-user/.ssh'.Enterpassphrase(emptyfornopassphrase):Entersamepassphraseagain:Youridentificationhasbeensavedin/home/cloudshell-user/.ssh/codecommit_key.Yourpublickeyhasbeensavedin/home/cloudshell-user/.ssh/codecommit_key.pub.Thekeyfingerprintis:SHA256:AJ1EUBde/TT0K/D6SqaryVdSEalDPVN8K/Lp55yWPrUcloudshell-user@ip-10-1-34-183.ec2.internalThekey'srandomartimageis:+---[RSA2048]----+|o*+.o.oo=o.||.ooo*..oo||.o..+o..o||.ooo....||Soooo.||...o..||o+.+||...+...E.||+oo....==.|+----[SHA256]-----+Listing6-19GeneratingSSHkeypair清单6-19中生成的密钥对被命名为codecommit_key，因此生成的公钥将被命名为codecommit_key.pub，而私钥是codecommit_key，两者都存储在目录/home/cloudshell-user/中。宋承宪。

接下来，为预期的IAM用户将公钥上传到AWS。要上传IAM用户的SSH公钥，请访问安全凭证设置，如图6-7所示。在安全凭证中，开始上传的选项如图6-10所示。

图6-10

开始SSH公钥上传

将提供SSH公钥的内容，如图6-11所示。在本例中，这是codecommit_key.pub的内容。您可以检索清单6-20中所示的内容。

图6-11

添加SSH公钥内容

$cat~/.ssh/codecommit_key.pubListing6-20RetrivingSSHpublickeycontent公钥上传成功后，生成SSH密钥ID，如图6-12所示。检索SSH密钥ID，因为它将用于本地Git配置。

图6-12

上传的公钥的SSH密钥ID

本地Git配置存储在。ssh文件夹，如清单6-21所示。配置文件中的主机字段是跨所有区域的CodeCommitURL模式，用户字段是应该用于连接的SSH用户，(这是从AWSIAM检索的SSH密钥ID，如图6-12所示)，而标识文件字段指向存储SSH私钥的位置。

$vim~/.ssh/configHostgit-codecommit.*.amazonaws.comUserAPKASOKDM2HTO6CTLRZSIdentityFile~/.ssh/codecommit_keyListing6-21LocalSSHconfiguration读写权限也应该添加到配置文件权限中，如清单6-22所示。

$chmod600.ssh/configListing6-22Settingconfigfilepermission现在配置了SSH，您可以通过克隆一个新创建的存储库，用它的SSHURL连接到CodeCommit存储库，如清单6-23所示。

$gitclonessh://git-codecommit.us-east-1.amazonaws.com/v1/repos/devops-ios-repositoryCloninginto'devops-ios-repository'...Theauthenticityofhost'git-codecommit.us-east-1.amazonaws.com(52.94.229.29)'can'tbeestablished.RSAkeyfingerprintisSHA256:eLMY1j0DKA4uvDZcl/KgtIayZANwX6t8+8isPtotBoY.RSAkeyfingerprintisMD5:a6:9c:7d:bc:35:f5:d4:5f:8b:ba:6f:c8:bc:d4:83:84.Areyousureyouwanttocontinueconnecting(yes/no)yesWarning:Permanentlyadded'git-codecommit.us-east-1.amazonaws.com,52.94.229.29'(RSA)tothelistofknownhosts.warning:Youappeartohaveclonedanemptyrepository.$cddevops-ios-repository/$gitstatusOnbranchmasterNocommitsyetnothingtocommit(create/copyfilesanduse"gitadd"totrack)Listing6-23ConnectingtoCodeCommitrepositorywithSSHGit远程代码提交(GRC)当您使用具有IAM角色的临时凭据来连接AWS时，会使用此选项。临时凭证的常见用例是身份联合、跨帐户访问和AWS服务(如EC2)的角色。

GRC是一个必须安装在工作站上的工具(git-remote-codecommit)，在这种方法中，GRC获取执行git操作的用户的当前AWS凭据，并使用它们对codecommit进行身份验证；因此，不需要IAM永久用户。

GRC需要安装Python，可以用pip安装，如清单6-24所示。

$pipinstallgit-remote-codecommitListing6-24InstallingGitremoteCodeCommit为了演示git-remote-codecommit如何工作，我将假设一个IAM角色，并使用为IAM角色生成的临时凭证来连接到存储库。

将要承担的IAM角色的配置如图6-13所示。

图6-13

具有AWS代码提交权限的IAM角色

为了获得临时凭证，我将使用AWSCLI承担IAM角色，如清单6-25所示。其中如图6-13所示的角色ARN被传递给--role-arn标志，并且在--role-session-name标志中为会话名称提供一个描述性名称。

$awsstsassume-role--role-arn"arn:aws:iam::123456789101:role/CodeCommitRole"--role-session-nameAWSCLI-SessionListing6-25AssumingIAMrole此AWSCLI操作返回临时凭据作为输出，并返回凭据的过期信息。检索AccessKeyId、SecretAccessKey、SessionToken，配置将要执行Git操作的工作站，如清单6-26所示。

$exportAWS_ACCESS_KEY_ID=$exportAWS_SECRET_ACCESS_KEY=$exportAWS_SESSION_TOKEN=Listing6-26Configureworkstationwithtemporarycredentials您的工作站现在应该正在使用临时凭证。您可以验证临时凭证是否配置正确并且是活动的，如清单6-27所示。

$awsstsget-caller-identity{"UserId":"AROASOKDM2HTNVOJHAAV7:AWSCLI-Session","Account":"123456789101","Arn":"arn:aws:sts::123456789101:assumed-role/CodeCommitRole/AWSCLI-Session"}Listing6-27Verifyingtemporarycredentials在验证临时凭证是活动的之后，我可以通过克隆一个新创建的存储库，使用GRCURL连接到存储库，如清单6-28所示。

$gitclonecodecommit::us-east-1://devops-ios-repositoryCloninginto'devops-ios-repository'...warning:Youappeartohaveclonedanemptyrepository.$cddevops-ios-repository/$gitstatusOnbranchmasterNocommitsyetnothingtocommit(create/copyfilesanduse"gitadd"totrack)Listing6-28ConnectingtoCodeCommitrepositorywithGitremoteCodeCommit将代码推送到代码提交存储库现在，我们已经探索了通过在本地克隆一个空的CodeCommit存储库来连接到CodeCommit存储库的不同方法，让我们向本地存储库添加一些源代码，并将更改推送到CodeCommit。

在将源代码添加到本地目录但还没有提交到Git之后，可以检查存储库的状态，如清单6-29所示，在这里您会看到新文件被列为未跟踪。

$gitstatusOnbranchmasterNocommitsyetUntrackedfiles:(use"gitadd..."toincludeinwhatwillbecommitted)SampleApp.xcodeproj/SampleApp/SampleAppTests/SampleAppUITests/nothingaddedtocommitbutuntrackedfilespresent(use"gitadd"totrack)Listing6-29Checkingthestatusofnewfilesaddedtolocalrepository然后，新添加的文件被暂存并提交给Git，如清单6-30所示。

$gitadd.$gitcommit-m"AddSampleApplicationCode"[master(root-commit)4c25bde]AddSampleApplicationCode34fileschanged,981insertions(+)createmode100644SampleApp.xcodeproj/project.pbxprojcreatemode100644SampleApp.xcodeproj/project.xcworkspace/contents.xcworkspacedatacreatemode100644SampleApp.xcodeproj/project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plistcreatemode100644SampleApp.xcodeproj/project.xcworkspace/xcuserdata/olaoyea.xcuserdatad/UserInterfaceState.xcuserstatecreatemode100644SampleApp.xcodeproj/xcuserdata/olaoyea.xcuserdatad/xcschemes/xcschememanagement.plistcreatemode100644SampleApp/Assets.xcassets/AccentColor.colorset/Contents.jsoncreatemode100644SampleApp/Assets.xcassets/AppIcon.appiconset/1024.pngcreatemode100644.........................................................................................................................................................Listing6-30CommittingsourcecodetoGit然后，通过简单地运行Gitpush将更改推送到CodeCommit，如清单6-31所示。

$gitpushWarning:PermanentlyaddedtheRSAhostkeyforIPaddress'52.94.233.146'tothelistofknownhosts.Enumeratingobjects:45,done.Countingobjects:100%(45/45),done.Deltacompressionusingupto2threadsCompressingobjects:100%(40/40),done.Writingobjects:100%(45/45),75.21KiB|6.84MiB/s,done.Total45(delta1),reused0(delta0)Tossh://git-codecommit.us-east-1.amazonaws.com/v1/repos/devops-ios-repository*[newbranch]master->masterListing6-31PushingchangestoCodeCommit将Git存储库迁移到AWS代码提交现有的远程Git存储库也可以迁移到CodeCommit。要迁移到CodeCommit，将在本地克隆存储库，然后将其推送到目标CodeCommit存储库。

例如，我想将一个名为devoPS-on-AWS-IOs-development的私有GitHub存储库迁移到一个名为target-CodeCommit-repository的CodeCommit存储库。首先，我将源GitHub存储库克隆到一个临时的本地目录，我将其命名为migrate-to-codecommit，如清单6-32所示。传递的--mirror标志用于克隆用于迁移的远程存储库的裸副本。

$cdmigrate-to-codecommit/$gitpush--allssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/target-codeommit-repositoryEnumeratingobjects:97,done.Countingobjects:100%(97/97),done.Deltacompressionusingupto2threadsCompressingobjects:100%(86/86),done.Writingobjects:100%(97/97),291.28KiB|10.40MiB/s,done.Total97(delta11),reused0(delta0)Tossh://git-codecommit.us-east-1.amazonaws.com/v1/repos/target-codeommit-repository*[newbranch]main->mainListing6-33PushingcontentstothedestinationCodeCommitrepository此时，GitHub库已经迁移到AWSCodeCommit，临时本地目录migrate-to-codecommit可以删除了。新迁移的仓库如图6-14所示。

图6-14

CodeCommit中迁移的存储库

要开始与CodeCommit存储库交互，您必须将存储库克隆到本地。清单6-34显示了临时迁移目录的删除和本地迁移存储库的克隆。

$rm-rfmigrate-to-codecommit/$gitclonessh://git-codecommit.us-east-1.amazonaws.com/v1/repos/target-codeommit-repositoryCloninginto'target-codeommit-repository'...Warning:PermanentlyaddedtheRSAhostkeyforIPaddress'52.94.226.180'tothelistofknownhosts.remote:Countingobjects:97,done.Receivingobjects:100%(97/97),291.28KiB|15.33MiB/s,done.Resolvingdeltas:100%(11/11),done.Listing6-34CloningmigratedrepositorytolocalAWS代码提交中分支在CodeCommit中创建分支有不同的方法，当您第一次提交到CodeCommit存储库时，会创建一个名为main的默认分支。接下来，我将向您展示如何使用AWS控制台、Git和AWSCLI创建额外的分支。

从CodeCommit存储库控制台中，选择分支菜单，如图6-15所示。

图6-15

从代码提交存储库控制台访问分支菜单

在下一页开始创建分支，如图6-16所示。如前所述，存储库的默认主分支已经存在。

图6-16

开始分支创建

创建分支时，必须选择要从中创建新分支的分支。如图6-17所示，一个名为dev的分支正在从唯一存在的分支main中创建。

图6-17

创建新的开发分支

创建的新开发分支可以在图6-18中看到。两个分支的最后一个提交消息是相同的，这是因为dev分支是新创建的，没有添加额外的提交。

图6-18

创建了新的开发分支

CodeCommit中的新分支也可以从Git命令行使用Git创建。当从Git命令行创建分支时，最初只在本地创建，必须将分支推送到CodeCommit，以便在CodeCommit上创建。

清单6-35显示了在本地创建一个新的分支，以及在CodeCommit上创建这个分支的推送操作。

$cdtarget-codeommit-repository/$gitcheckout-btestSwitchedtoanewbranch'test'$gitpushorigintestTotal0(delta0),reused0(delta0)Tossh://git-codecommit.us-east-1.amazonaws.com/v1/repos/target-codeommit-repository*[newbranch]test->testListing6-35CreateCodeCommitbranchusingGit在CodeCommit控制台上可以看到新创建的分支测试，如图6-19所示。

图6-19

从Git创建的新测试分支

要使用AWSCLI创建分支，除了将存储库名称和分支名称作为参数传递之外，还必须指定要从中创建分支的GitcommitID。要检索Git提交ID，您可以访问您的CodeCommit存储库的所有提交，如图6-20所示。

图6-20

访问代码提交资料档案库的所有提交

您可以复制提交ID来创建新的分支，如图6-21所示。

图6-21

复制提交ID

知道了用于分支创建的提交ID后，就可以使用AWSCLI创建新的分支，如清单6-36所示。

$awscodecommitcreate-branch--repository-nametarget-codeommit-repository--branch-namepreprod--commit-id7da70dd7ef5eb237012ac0699367922d9cb3524eListing6-36CreatingbranchusingAWSCLI如图6-22所示，可以在代码提交控制台上看到新创建的预编程分支。

图6-22

使用AWSCLI创建新的预编程分支

随着所有新分支的创建，一些分支存在于CodeCommit中，但不在本地，您可以获取远程存储库的更新并查看所有分支，如清单6-37所示。

$gitremoteupdateoriginFetchingoriginFromssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/target-codeommit-repository*[newbranch]preprod->origin/preprod$gitbranch--alldev*testremotes/origin/HEAD->origin/devremotes/origin/devremotes/origin/mainremotes/origin/preprodremotes/origin/testListing6-37Fetchupdatefromremoterepository配置默认分支当您第一次提交到CodeCommit存储库时，会为您创建一个名为main的默认基础分支。如果需要，可以将这个默认分支更改为存储库中的其他分支。要更改默认分支，请转到如图6-23所示的存储库设置。

图6-23

存储库设置

在默认分支菜单中，可以从库分支列表中选择新的默认分支，如图6-24所示。

图6-24

选择默认分支

AWS代码提交存储库支持在合并分支之前创建拉请求。还有一些额外的特定于CodeCommit的pullrequest特性，比如批准规则和AmazonCodeGuruReviewer集成。接下来让我们探索所有这些概念。

当两个分支合并时，例如，一个功能分支与一个主分支合并，可以在AWS控制台或CLI上创建一个拉请求。

在您可以创建一个拉请求来合并两个分支之前，这两个分支之间必须有一个增量。一个增量被引入到本地存储库中的一个测试分支，并被推送到远程代码提交存储库中，如清单6-38所示。

$echo"AddNewText">>README.md$gitstatusOnbranchtestChangesnotstagedforcommit:(use"gitadd..."toupdatewhatwillbecommitted)(use"gitrestore..."todiscardchangesinworkingdirectory)modified:README.mdnochangesaddedtocommit(use"gitadd"and/or"gitcommit-a")$gitaddREADME.md$gitcommit-m"AddnewtexttoReadme"[test7ea6176]AddnewtexttoReadme1filechanged,1insertion(+)$gitpush--set-upstreamorigintestEnumeratingobjects:5,done.Countingobjects:100%(5/5),done.Deltacompressionusingupto2threadsCompressingobjects:100%(2/2),done.Writingobjects:100%(3/3),311bytes|311.00KiB/s,done.Total3(delta1),reused0(delta0)Tossh://git-codecommit.us-east-1.amazonaws.com/v1/repos/target-codeommit-repository7da70dd..7ea6176test->testBranch'test'setuptotrackremotebranch'test'from'origin'.Listing6-38AddingchangestorepositorytestbranchandpushingtoCodeCommit既然代码更改已经被推送到CodeCommit存储库的测试分支，就可以创建一个pull请求了。

要创建一个拉请求，您可以访问存储库的拉请求页面，如图6-25所示。

图6-25

访问拉取请求控制台

在存储库的Pullrequests页面上，您可以开始创建Pullrequests，如图6-26所示。

图6-26

开始创建拉取请求

如图6-27所示选择源和目的分支。对于这个例子，包含代码变更的源分支是测试，目标分支是主。

图6-27

选择源和目标分支

为拉取请求提供标题和可选描述，如图6-28所示。通常，该描述将包含代码更改的细节，以便为将要审查它的团队成员提供上下文。

图6-28

为拉取请求提供标题和描述

在最终创建拉请求之前，您可以检查由源分支引入的变更，如图6-29所示。

图6-29

查看由“拉”请求引入的更改

最后，一旦成功创建了拉请求，新的拉请求将如图6-30所示。

图6-30

已创建拉取请求

为了在AWSCLI上创建一个拉请求，我们使用清单6-39中的命令。拉请求标题被传递给--title选项，描述被传递给--description选项，您生成的惟一幂等令牌应该被传递给--client-request-token选项，存储库和分支信息被传递给--targets选项。

$awscodecommitcreate-pull-request--title"MergeTesttoMainBranch"--description"Exampledescription"--client-request-tokenExample--targetsrepositoryName=target-codeommit-repository,sourceReference=Test,destinationReference=mainListing6-39CreatingpullrequestwiththeAWSCLI合并拉取请求一旦“拉”请求被其他人审阅并准备好合并，这个操作也可以在AWS控制台或CLI上执行。

只要两个分支是可合并的，即没有合并冲突或批准规则会阻止合并，合并选项总是被激活，如图6-31所示。

图6-31

开始提取请求合并

要合并，必须选择一个合并策略；CodeCommit支持三种不同的合并策略，如图6-32所示。合并的默认Git行为是尽可能快进。如果由于合并方案而无法应用特定的合并类型，此选项将灰显且无法选择。成功合并后，您可以选择删除源分支，选择此选项后，本例中使用的测试分支将从存储库中删除。

图6-32

选择合并类型和合并提取请求

一旦拉请求被成功合并，你会得到一个确认，如图6-33所示。

图6-33

已合并拉取请求

要查看所应用的合并更改，您可以切换到存储库中的目标分支，并检查由pull请求所做的文件更改。如图6-34所示，拉取请求更新的仓库的README.md已经被更改。

图6-34

来自拉取请求的更新文件

现在远程主分支已经更新，为了保持本地主分支也是最新的，必须执行一个gitpull操作，如清单6-40所示。

$awscodecommitmerge-pull-request-by-fast-forward--pull-request-id1--source-commit-idEXAMPLE1112222333--repository-nametarget-codeommit-repositoryListing6-41Mergingusingfastforwardstrategy创建审批规则模板批准规则模板允许您自动将批准规则应用于在存储库中创建的提取请求。在每个AWS区域中，您可以将批准规则模板应用于在所有CodeCommit存储库中创建的部分或全部拉请求。

使用批准规则模板，您可以在为给定分支(例如，您的主分支)创建提取请求时自动应用批准规则，并在合并提取请求之前要求某些团队成员的批准。

让我们看看如何在AWS控制台和CLI上创建批准模板。

您可以在AWS控制台上访问审批规则模板页面，如图6-35所示。

图6-35

访问审批规则模板页面

您可以开始创建审批规则模板，如图6-36所示。

图6-36

开始创建审批规则模板

我正在创建的审批规则模板定义如图6-37所示。批准的最小数量定义为1，还提供了有效批准人的列表。这里我提供一个Iam用户的ARN；还指定了要应用规则的目标分支。最后，指定要应用该模板的存储库列表。

图6-37

审批规则模板定义

要在AWSCLI上创建批准规则模板，必须首先在JSON中定义该模板，如清单6-42所示。定义的示例模板应用于存储库的主分支，需要两次批准，批准者列表中提供了IAM用户ARN。

{"Version":"2018-11-08","DestinationReferences":["refs/heads/main"],"Statements":[{"Type":"Approvers","NumberOfApprovalsNeeded":2,"ApprovalPoolMembers":["arn:aws:iam::123456789101:user/abdullahi"]}]}Listing6-42Approvalruletemplatedefinition该模板可以提供给AWSCLI命令，如清单6-43所示。审批模板名称在--approval-rule-template-name选项中提供，描述在--approval-rule-template-description选项中提供，模板JSON定义在--approval-rule-template-content选项中提供。

图6-38

应用审批规则的提取请求

一旦拉动请求被批准，批准规则要求就被满足，合并按钮出现，如图6-39所示。

图6-39

审批后合并拉取请求

目前CodeGurureviewer只支持审查Java和Python代码。

图6-40

CodeCommit存储库设置中的CodeGuruReviewer选项卡

将CodeGuruReviewer关联到您的CodeCommit存储库，如图6-41所示。

图6-41

协会代码专家评审员

关联不会立即完成，而关联状态是关联。如图6-42所示，关联需要10分钟。

图6-42

CodeGuru审阅者关联正在进行中

关联完成后，状态变为关联。解除存储库关联的选项也会出现，如图6-43所示。

图6-43

CodeGuru审查者关联

importboto3s3_client=boto3.client('s3')s3_client.list_objects(Bucket="BucketName")Listing6-44ExamplePythoncodetotriggerCodeGurureviewer我将这个代码片段添加到我的存储库的dev分支中的一个.py文件中，并创建一个pull请求来合并到主分支中。CodeGurureviewer自动开始审查pull请求，如图6-44所示。

图6-44

CodeGuru审核者审核拉取请求

完成审查后，如果在拉请求中发现任何缺陷，它会留下一个注释。如图6-45所示，我在代码中使用了一个过时的API，CodeGurureviewer建议使用修改后的API。

图6-45

iOS应用开发流程的自动化和编排始于源代码控制管理。在这一章中，我们介绍了Git版本控制系统的基础知识，然后深入探讨了AWSCodeCommit的Git特性，以及如何使用它作为一个私有的远程Git存储库，并附有演练示例。然后，我们介绍了它与AmazonCodeGuruReviewer的集成，通过机器学习自动审查Python和Java代码。

当应用源代码存储在AWSCodeCommit中以进行源代码控制时，它可以与其他构建和测试系统集成以进行持续集成，以便当在源存储库中进行新的提交时，触发自动构建和/或测试。

在本章中，我们将看到AWSCodeCommit如何使用Jenkins插件与Jenkins集成。通过这种集成，可以使用AWSCodeCommitforsourcecontrol在Jenkins上设置iOS应用构建作业，其中当代码提交到AWSCodeCommit时，在Jenkins上触发构建。

插件用于增强Jenkins的功能，以适应特定的用例，它允许各种工具和云提供商与Jenkins集成。为了集成AWSCodeCommit和Jenkins，使用了一个AWSCodeCommit插件。

当通过亚马逊简单通知服务(SNS)进行提交时，JenkinsAWSCodeCommit插件通过向亚马逊简单队列服务(SQS)队列发送消息来工作。Jenkins作业定期轮询队列中的任何新消息，如果发现新消息，则触发作业的新构建。

要在Jenkins控制器上安装该插件，图7-1显示了如何从Jenkins环境主页访问管理Jenkins页面。

图7-1

访问管理Jenkins控制台

在设置控制台上，有各种配置Jenkins环境的选项，如图7-2；您可以访问“管理插件”页面来管理插件。

图7-2

管理Jenkins插件

所有安装在Jenkins环境中的插件都可以在这个页面上管理，从不同的可用选项卡可以看到。Updates选项卡显示任何已安装的插件，该更新了，Available选项卡显示可以安装在Jenkins环境中的所有可用插件，Installed选项卡显示安装在该Jenkins环境中的所有Jenkins插件，Advanced选项卡提供执行操作的选项，如通过手动上传档案来安装插件。使用高级选项的一个用例是当您想要安装一个通过webUI不可用的插件的旧版本时。

要开始安装AWSCodeCommit插件，切换到Available选项卡并搜索CodeCommit，如图7-3所示。

图7-3

正在搜索AWS代码提交插件

选择AWSCodeCommit触发器并安装，如图7-4所示。你可以指示Jenkins立即安装而不重启，或者下载并等待下次重启来安装插件。

图7-4

正在安装AWS代码提交插件

现在已经安装了插件，要开始在项目中使用插件，必须对它进行配置。但是，要配置该插件，作为先决条件，需要设置一些AWS资源。

在下一节中，我们将看到如何设置这些先决资源。

要配置在上一节中安装的AWSCodeCommitJenkins插件，我们需要创建一个AmazonSQS队列和AmazonSNS主题，并配置CodeCommit存储库，以便在创建新的提交时将消息发布到SQS队列。

在本节中，我们将通过AWS控制台手动设置这些组件。

要访问亚马逊简单队列服务(SQS)控制台，在AWS控制台上搜索SQS，如图7-5所示。

图7-5

在AWS管理控制台上搜索SQS

开始创建SQS队列，如图7-6所示。

图7-6

开始创建SQS队列

图7-7显示了如何配置SQS队列的示例。对于这个用例，标准队列类型就足够了。

图7-7

配置和创建SQS队列

要访问亚马逊简单通知服务(SNS)控制台，在AWS控制台上搜索SNS，如图7-8所示。

图7-8

在AWS管理控制台上搜索SNS

开始创建一个SNS主题，如图7-9所示。

图7-9

开始创建SNS主题

SNS主题的配置示例如图7-10所示。标准的SNS主题类型适合这个用例。

图7-10

配置和创建sns主题

既然已经创建了一个SQS队列和一个SNS主题，那么通过为SNS主题订阅SQS队列，这两个队列将被集成在一起。SNS主题向其订阅的所有实体发布消息；当SQS队列接收到来自SNS主题的消息时，它会存储该消息，直到消费者使用队列中的消息。在这种情况下，消费者是运行在Jenkins中的AWSCodeCommit插件。

访问创建的SNS主题并创建订阅，如图7-11所示。

图7-11

开始创建订阅

由于订阅是为SQS队列创建的，因此应该相应地选择亚马逊SQS协议和相应的SQS队列，如图7-12所示。

图7-12

配置和创建亚马逊SQS订阅

成功创建SQS订阅的示例如图7-13所示。

图7-13

成功创建SQS订阅

要允许SNS主题向SQS队列发布消息，应该将SQS队列的访问策略配置为允许访问SNS主题。要配置SQS队列访问策略，从SQS队列进入访问策略页签，如图7-14所示。

图7-14

配置SQS队列访问策略

默认情况下，帐户中的IAM身份可以访问创建的SQS队列，但是要允许访问SNS等AWS服务，需要修改访问策略。

清单7-1显示了一个示例策略，该策略可以应用于访问策略，以允许SNS主题向SQS队列发布消息。

{"Version":"2008-10-17","Id":"__default_policy_ID","Statement":[{"Sid":"__owner_statement","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789101:root"},"Action":"SQS:*","Resource":"arn:aws:sqs:us-east-1:123456789101:codecommit-trigger-queue"},{"Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"arn:aws:sqs:us-east-1:123456789101:codecommit-trigger-queue","Condition":{"ArnEquals":{"aws:SourceArn":"arn:aws:sns:us-east-1:123456789101:codecommit-trigger-topic"}}}]}Listing7-1SQSqueueaccesspolicy测试SQS和社交网络整合随着SQS队列访问策略的配置，亚马逊SQS和亚马逊SNS的集成就完成了。可以通过在SNS主题中手动发布消息并验证消息是否在SQS队列中收到来测试集成。

在SNS话题上发布消息，如图7-15所示。

图7-15

社交网络发布消息

提供测试消息主题和消息体，如图7-16所示。该消息将被分发给订阅SNS主题的所有实体。

图7-16

提供测试消息主题和正文

切换到SQS队列控制台，验证消息是否已收到。在SQS队列上，您可以开始接收如图7-17所示的消息。

图7-17

正在SQS队列上接收消息

可以轮询和查看消息，如图7-18所示。将显示队列中的所有消息。要轮询消息，点击轮询消息选项，如图7-18所示。

图7-18

轮询和查看SQS队列中的消息

队列中的消息验证从SNS发布的消息是否被传递到SQS。

要查看消息内容，点击消息ID，如图7-18所示。消息内容将类似于清单7-2。

您可以配置特定存储库事件或所有存储库事件来触发操作。对于操作，您可以调用AWSlambda函数或向AmazonSNS主题发送通知。我们将了解存储库事件如何向AmazonSNS主题发送通知。

首先，从您希望使用的CodeCommit库，转到设置页面，如图7-19所示。

图7-19

代码提交存储库设置

从触发器页签创建一个触发器，如图7-20所示。

图7-20

开始代码提交触发器创建

如图7-21所示配置并创建触发器。对于SNS主题，选择出于相同目的集成到SQS队列中的SNS主题。

图7-21

配置和创建代码提交触发器

让我们通过TerraformforinfrastructureasCode(IaC)来设置所需的AWS资源。

清单7-3显示了设置所有所需资源的示例Terraform代码片段。

$terraforminitInitializingthebackend...Initializingproviderplugins...-Findinglatestversionofhashicorp/aws...-Installinghashicorp/awsv3.59.0...-Installedhashicorp/awsv3.59.0(signedbyHashiCorp)Terraformhascreatedalockfile.terraform.lock.hcltorecordtheproviderselectionsitmadeabove.IncludethisfileinyourversioncontrolrepositorysothatTerraformcanguaranteetomakethesameselectionsbydefaultwhenyourun"terraforminit"inthefuture.Terraformhasbeensuccessfullyinitialized!YoumaynowbeginworkingwithTerraform.Tryrunning"terraformplan"toseeanychangesthatarerequiredforyourinfrastructure.AllTerraformcommandsshouldnowwork.IfyoueversetorchangemodulesorbackendconfigurationforTerraform,rerunthiscommandtoreinitializeyourworkingdirectory.Ifyouforget,othercommandswilldetectitandremindyoutodosoifnecessary.Listing7-4InitializingTerraform成功初始化后，所有依赖项都已下载，现在您可以运行terraformapply来部署资源。该命令的输出将类似于清单7-5中所示的示例片段。

$terraformapplyprovider.aws.regionTheregionwhereAWSoperationswilltakeplace.Examplesareus-east-1,us-west-2,etc.Enteravalue:us-east-1...DoyouwanttoperformtheseactionsTerraformwillperformtheactionsdescribedabove.Only'yes'willbeacceptedtoapprove.Enteravalue:yes...Applycomplete!Resources:6added,0changed,0destroyed.Outputs:sns-arn="arn:aws:sns:us-east-1:123456789101:codecommit-target-codeommit-repository-topic"sns-name="codecommit-target-codeommit-repository-topic"Listing7-5CreatingresourceswithTerraform配置插件已经设置的插件先决条件资源是SQS队列、SNS主题、为SNS主题订阅SQS队列，以及设置CodeCommit触发器以在存储库事件时向插件SNS主题发送通知。现在，插件可以配置为利用已经创建的资源来完成集成。

要配置插件，进入Jenkins系统配置，如图7-22所示。

图7-22

配置Jenkins系统

在系统配置页面上，可以看到CodeCommit插件配置。图7-23显示了如何开始用已经创建的SQS队列配置插件。

图7-23

将SQS配置添加到代码提交插件

应提供AWS区域和SQS队列名称，如图7-24所示。该插件使用提供的AWS凭证测试对SQS队列的访问。

图7-24

配置SQS队列名和AWS区域

如果可用，可以使用Jenkins上配置的现有AWS凭证，但是要添加新的AWS凭证，图7-25中显示了一个示例。

图7-25

向Jenkins添加AWS凭据

JenkinsCodeCommit插件现在应该已经配置好并处于活动状态。接下来，我们将创建一个示例Jenkins作业来验证插件是如何工作的。

在本节中，我们将看到一个示例Jenkins作业如何使用AWSCodeCommit源代码，以及如何使用已配置的JenkinsCodeCommit插件进行自动构建。图7-26显示了如何开始创建Jenkins作业。

图7-26

开始创建Jenkins作业

我们将创建一个Jenkins自由式项目。如图7-27所示，需要提供项目名称。

图7-27

创建Jenkins自由式项目

对于项目配置，需要将本章前面配置的CodeCommit库添加到源代码管理(SCM)中，如图7-28所示。

图7-28

使用AWS代码提交配置SCM

如果可用，可以使用Jenkins上配置的现有CodeCommitGit凭证，但要添加新的Git凭证，图7-29中显示了一个示例。这里提供的Git凭据是CodeCommitIAM用户的HTTPS凭据。

图7-29

配置代码提交HTTPS凭据

为自动构建配置构建触发器，如图7-30所示。显示了将由插件监控的SQS队列。

图7-30

设置构建触发器

对于构建，输入一些基本的示例命令，如图7-31所示，项目就创建好了。当一个构建被触发时，存储库的内容被克隆到Jenkins工作空间，图7-31中提供的命令列出工作空间并确认存储库内容是否被下载。

图7-31

输入构建命令

图7-32中可以看到一个自由式项目的例子。

图7-32

Jenkins自由式项目

为了测试该插件，将在CodeCommit存储库中创建一个新的提交，这将触发Jenkins上的自动构建。

清单7-6显示了在CodeCommit存储库中创建一个新的提交，该存储库被配置为示例Jenkins作业的源。

$touchtestfile$gitadd.&&gitcommit-m"Testlistingdirectory"[masterfb68e27]Testlistingdirectory1filechanged,0insertions(+),0deletions(-)createmode100644testfile$gitpushEnumeratingobjects:4,done.Countingobjects:100%(4/4),done.Deltacompressionusingupto6threadsCompressingobjects:100%(2/2),done.Writingobjects:100%(3/3),285bytes|285.00KiB/s,done.Total3(delta1),reused0(delta0),pack-reused0Tocodecommit::us-east-1://devops-ios-repositorybc42da1..fb68e27master->masterListing7-6AddingcommittoAWSCodeCommitRepository在Jenkins项目上，您可以验证该项目是从新提交自动启动的，如图7-33所示。

图7-33

Jenkins作业自动构建

图7-34显示了包含所有构建命令输出的构建日志。

图7-34

Jenkins工作构建输出

Jenkins是DevOps中使用非常广泛的工具，因为它具有丰富的功能，能够与许多其他工具集成以满足不同的用例，这也是它对iOS开发非常有用的原因。当iOS应用的源代码存储在AWSCodeCommit上时，将CodeCommit与Jenkins集成以实现端到端自动化变得至关重要。

到目前为止，我们已经深入研究了将Jenkins和CodeCommit集成到自动化Jenkins构建和基本构建中的过程。接下来，我们将从这里开始，向Jenkins添加更多特定于iOS的构建和测试。

在前一章中，我们学习了如何将存储在AWSCodeCommit中的应用源代码与Jenkinsjobs集成，以便在代码发生更改时实现自动构建。拥有一个在代码更改时自动调用的构建系统是持续集成和持续交付或部署(CICD)的关键要求，因此在本章中，我们将利用自动化构建，深入探讨如何使用Jenkins和Fastlane来自动化构建、测试和发布iOS应用。

有了Fastlane匹配，开发团队可以共享一个代码签名身份，以帮助简单的代码签名。它创建所有必需的签名资源，如证书、配置文件，并将它们存储在一个集中的位置，这样每个团队成员都可以检索这些证书并用于代码签名。当使用Fastlane进行应用开发和发布时，这变得无缝，因为从集中位置检索凭证和配置构建系统的过程是内置在Fastlane的。在持续集成和持续交付或部署(CICD)系统中使用Fastlane时，这一点特别有用，因为可以从集中位置自动检索凭证，并无缝构建应用。

对于代码签名凭证的集中存储，让我们看看如何将亚马逊S3用作Fastlane匹配的存储位置。在本章的后面，我们将看到如何在应用构建过程中从S3检索这些凭证，以便对构建工件进行签名。

必须首先在本地开发工作站上的项目文件夹中设置Fastlane匹配。但是首先必须在开发工作站上安装Fastlane。安装Fastlane有多种方法，但最简单的方法是使用自制软件，如清单8-1所示。

$brewinstallfastlaneListing8-1InstallingFastlanewithHomebrew在Fastlane安装之后，从iOS项目目录中初始化match，如清单8-2所示。

对于存储模式，如清单8-2所示，match支持不同的存储模式，但我们将重点使用S3作为存储模式，因此选择S3。

清单8-2。初始化匹配

初始化时，它在项目目录中创建一个名为Matchfile的文件。该文件将包含成功执行match所需的所有必要信息。最初，该文件不会包含所有信息，但接下来我们将配置所需的信息。

我们首先为集中式存储创建一个S3存储桶，并配置AWS凭证环境变量，允许Fastlane访问S3存储桶，如清单8-3所示。还配置了唯一的匹配密码；此密码用于加密/解密证书。

记下存储桶名称、用于AWS凭证的环境变量名称以及匹配密码。

$awss3mbs3://abdullahi-fastlane-certificates$exportAWS_SECRET_ACCESS_KEY=xxxxxxxxxxx$exportAWS_ACCESS_KEY_ID=xxxxxxxxxxxx$exportMATCH_PASSWORD=xxxxxxxxxxxListing8-3CreatingS3bucketandconfiguringenvironmentvariables使用创建的S3存储桶和在清单8-3中配置的AWS凭证环境变量，从清单8-2创建的匹配文件被定制。清单8-4中显示了匹配文件的示例内容。

配置好匹配文件后，现在我们可以生成证书并存储在集中式S3存储桶中。清单8-5展示了如何为开发和示例输出生成证书的示例。清单8-5中的命令生成了很多输出，所以只显示了一个片段。

清单8-5。Fastlane生成发展凭证

当该命令完成时，签名凭证将被存储在上述S3桶中，如图8-1所示。

图8-1

每个团队ID的代码签名凭证存储在S3存储桶中

签名凭证由团队ID组织，在每个团队ID文件夹中，签名凭证的存储如图8-2所示。

图8-2

特定团队ID的签名凭据

如前所述，使用Fastlane匹配进行代码签名的主要好处是易于跨不同的开发人员和构建系统重用一个签名凭据。现在，签名凭证存储在一个集中的S3存储桶中，用于正确访问和使用这些存储的代码签名凭证的凭证也必须存储在一个集中的位置，以便在需要时可以方便地检索它们。

到目前为止，这些签名凭证的其他用户将需要的凭证是访问集中式S3桶的AWS凭证和解密代码签名凭证的匹配密码，所有这些都在清单8-3中进行了配置。应该存储的附加信息是S3桶名、应用标识符、苹果用户名和团队ID。

为了存储这些内容，我们将使用AWSSecretsManager，这是一个专为存储机密而设计的AWS服务。图8-3显示了如何在AWSSecretsManager中创建一个秘密来存储这些秘密。

图8-3

创建AWS机密管理器机密来存储Fastlane机密

在秘密创建之后，它应该在秘密列表上可见。图8-4显示了一次成功的秘密创建。

图8-4

验证秘密创建

接下来，我存储秘密，它应该是可见的，如图8-5所示。现在，作为构建过程的一部分，可以手动或以编程方式检索秘密。

图8-5

AWS机密管理器中存储的所有机密和参数

要使用Jenkins和Fastlane构建和发布iOS应用，需要在Jenkins环境中安装一些工具。本节将验证所需的工具。

对于任何iOS应用版本，都必须安装Xcode。从AppStore安装Xcode时，它也会安装Fastlane使用的命令行界面(CLI)工具。

Xcode安装后，确保接受许可协议并验证Xcode已成功启动，如图8-6所示。

图8-6

验证Xcode安装

还要验证Xcode命令行工具是否如清单8-6所示安装。

$xcode-select--versionxcode-select--versionxcode-selectversion2384.$xcodebuild-versionxcodebuild-versionXcode13.0Buildversion13A233$xcodebuildCommandlineinvocation:/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuildUserdefaultsfromcommandline:IDEPackageSupportUseBuiltinSCM=YESxcodebuild:error:Thedirectory/Users/userAdoesnotcontainanXcodeproject.Listing8-6VerifyingXcodeCLItools验证Fastlane安装验证Fastlane是否安装在Jenkins环境中，如清单8-7所示。

清单8-7。验证Fastlane安装

在Jenkins构建期间，AWSCLI将用于检索存储在AWSSecretManager中的所有Fastlane机密，因此需要在Jenkins环境中安装和配置AWSCLI。

AWSCLI可以按照清单8-8中所示进行验证和配置。

$brewinstalljqListing8-9Verifyingjqinstallation用Fastlane自动化测试和构建在这一节中，我们将重点介绍如何与Fastlane和Jenkins一起自动测试和构建iOS应用。

首先要将Fastlane添加到iOS应用项目中，应该在iOS项目的根文件夹中创建一个fastlane目录，并在Fastlane文件夹中创建一个名为Fastfile的文件，如清单8-10所示。

$mkdirfastlane$cdfastlane&&touchFastfileListing8-10CreatingFastlanedirectoryandFastfilefromprojectrootfolderFastfile是用Ruby编写的，包含了Fastlane在iOS应用上执行操作所需的所有指令。快速文件中的指令写在通道中。通道包含在iOS应用上执行特定操作的所有逻辑，当调用一组特定的指令时，通道的名称被传递给Fastlane命令。

清单8-11中显示了可以添加到清单8-10中新创建的Fastfile中的测试和构建示例通道。

lane:builddomatch(type:"appstore",storage_mode:"s3",s3_bucket:ENV["S3_BUCKET"],s3_access_key:ENV["AWS_ACCESS_KEY_ID"],s3_secret_access_key:ENV["AWS_SECRET_ACCESS_KEY"],app_identifier:ENV["APP_IDENTIFIER"],username:ENV["APPLE_DEVELOPER_USERNAME"],team_id:ENV["TEAM_ID"])increment_build_number(build_number:ENV["BUILD_ID"])gym(project:"SampleApp.xcodeproj")endlane:testdoscan(project:"SampleApp.xcodeproj",devices:["iPhoneXs"])endListing8-11AddingFastlanelanesfortestandbuildtoFastfile如图所示，有两条车道，即测试和建造。在通道配置中，存储在AWSSecretsManager中的所有参数都将被检索，并在构建时通过环境变量提供给Fastlane。

在前一章中，Jenkins项目已经建立并与AWSCodeCommit集成，用于自动构建。该项目将被扩展，以将iOS构建和测试逻辑添加到其构建配置中。在清单8-12中可以看到一个示例构建脚本。

图8-7

Jenkins构建配置

将Fastlane构建和测试通道添加到iOS项目中，并相应地配置Jenkins构建，然后可以在AWSCodeCommit中创建新的提交，以开始新的构建。代码可以被提交和推送，如清单8-13所示。

$gitadd.&&gitcommit-m"Buildandtestapp"[masterea9e896]Buildandtestapp1filechanged,1insertion(+),33deletions(-)$gitpushEnumeratingobjects:7,done.Countingobjects:100%(7/7),done.Deltacompressionusingupto6threadsCompressingobjects:100%(4/4),done.Writingobjects:100%(4/4),368bytes|368.00KiB/s,done.Total4(delta2),reused0(delta0),pack-reused0Tocodecommit::us-east-1://devops-ios-repositoryfb68e27..ea9e896master->masterListing8-13CommittingandpushingchangestoAWSCodeCommit这开始了对Jenkins的构建，如图8-8所示。

图8-8

开始iOS应用测试和构建的新承诺

在Jenkins中可以看到构建日志，但是清单8-14中显示了构建触发的日志片段。

清单8-14。Fastlane测试并构建Jenkins日志片段

AppStoreConnect允许您管理您的iOS应用。从那里，用户可以使用TestFlight分发iOS应用进行测试，并将应用发布到应用商店。要在AppStoreConnect上管理iOS应用，首先要将构建的应用上传到AppStoreConnect门户，然后在那里进行管理。

Fastlane还自动将iOS应用发布到AppStoreConnect。在本节中，我们将扩展在上一节中配置的Jenkins项目，该项目测试并构建应用，以添加一个将构建的应用发布到AppStoreConnect的操作。

我们将调查AppStoreConnect的两个用例，发布一个应用到TestFlight进行beta测试，发布一个应用将提交到AppStore。

为了让Fastlane在没有人工干预的情况下以编程方式与AppStoreConnect进行交互，将生成一个AppStoreConnectAPI密钥来认证Fastlane。要生成API密匙，你从AppStoreConnect仪表盘开始，访问用户，进入页面，如图8-9所示。

图8-9

AppStore连接仪表板

此页面列出了此Appledeveloper帐户的所有用户及其角色。如图8-10所示，切换到键选项卡。

图8-10

从“用户和访问”页面访问“密钥”选项卡

如果这是第一次为AppStoreConnectAPI生成APIkey，必须先请求访问，如图8-11所示。

图8-11

请求访问AppStore连接API

一旦访问请求被批准(通常是立即批准)，就可以生成一个API密钥，如图8-12所示。

图8-12

正在生成AppStore连接API密钥

提供API密钥的名称和访问级别。示例如图8-13所示。

图8-13

提供API键名并生成它

API密钥生成后，就可以下载了。下载API密钥，如图8-14所示。

图8-14

正在下载API密钥

下载API密钥后，下载选项不再可用，如图8-15所示。

图8-15

下载API密钥选项不可用

API密钥下载在p8扩展文件中。要在后续步骤中使用API密钥，它应该是base64编码的，如清单8-15所示。

$base64AuthKey_AxxxxxxxBY.p8>base64output.txtListing8-15Base64encodeAppStoreConnectAPIKey除了下载和base64编码的API密钥之外，发行者ID和密钥ID也应该被检索并存储在一个安全的位置。

从AppStoreConnect门户检索到的所有机密都将被构建过程使用，因此需要将这些机密存储在一个集中的安全位置，以便在构建时可以检索到它们。

对于这个用例，AWSSecretsManager将用于存储AppStoreConnectsecrets，类似于它用于存储Fastlane机密和参数的方式。如图8-16所示，创建一个新的秘密。

图8-16

创建机密以存储AppStore连接机密

然后如图8-17所示存储秘密。base64编码的API密钥存储为带有密钥API_KEY的值。从AppStoreConnect门户检索的密钥ID和发行者ID分别存储为带有密钥KEY_ID和App_Store_Connect_ISSUER_ID的值。

图8-17

存储AppStore连接机密

TestFlight允许iOS开发者邀请真实用户测试应用，以便在应用商店公开发布之前收集反馈。要使用TestFlight，需要构建应用并发布到AppStoreConnect。在这里，我们将看到如何应用发布到试飞可以自动与Fastlane。

扩展之前创建的配置了测试和构建通道的Fastfile，可以添加一个测试飞行通道。清单8-16显示了试飞的一个示例通道配置。

lane:testflightdoapi_key=app_store_connect_api_key(key_id:ENV["KEY_ID"],issuer_id:ENV["APP_STORE_CONNECT_ISSUER_ID"],key_content:ENV["API_KEY"],duration:1200,in_house:false,is_key_content_base64:true,)pilot(api_key:api_key,)EndListing8-16FastlanelaneforTestFlightrelease如清单8-16所示，密钥ID、发行者ID和API密钥将从AWSSecretsManager中检索，并通过环境变量提供，供构建流程在运行时使用Fastlane。

根据清单8-12配置的Jenkins构建脚本应该被修改以添加新的试飞车道，如清单8-17所示。

TestFlightlane已经添加到应用源代码Fastfile中，Jenkins项目也相应地进行了修改，现在可以通过在AWSCodeCommit中创建新的commit来触发Jenkins项目，如清单8-18所示。

$gitadd.&&gitcommit-m"Uploadtotestflight"[master3a1febb]Uploadtotestflight1filechanged,17insertions(+),1deletion(-)$gitpushEnumeratingobjects:7,done.Countingobjects:100%(7/7),done.Deltacompressionusingupto6threadsCompressingobjects:100%(4/4),done.Writingobjects:100%(4/4),580bytes|580.00KiB/s,done.Total4(delta2),reused0(delta0),pack-reused0Tocodecommit::us-east-1://devops-ios-repositoryea9e896..3a1febbmaster->masterListing8-18CreatinganewcommitinCodeCommitforTestFlight新提交在Jenkins上可见，如图8-18所示。

图8-18

触发试飞发布的新提交

清单8-19中显示了触发构建的日志片段。

清单8-19。试飞上传的Jenkins日志片段

从AppStoreConnect上的TestFlight控制台，可以看到刚刚上传的构建，如图8-19所示。

图8-19

Fastlane试飞上传

如果要将应用上传到AppStoreConnect进行AppStore提交，此过程也可以由Fastlane自动完成。

AppStore的lane配置也应该添加到前面操作中使用的同一个Fastfile中。清单8-20显示了应用商店上传的通道配置示例。

lane:appstoredoapi_key=app_store_connect_api_key(key_id:ENV["KEY_ID"],issuer_id:ENV["APP_STORE_CONNECT_ISSUER_ID"],key_content:ENV["API_KEY"],duration:1200,in_house:false,is_key_content_base64:true,)deliver(api_key:api_key,force:true,run_precheck_before_submit:false)EndListing8-20AppStorelaneconfiguration类似地，对于其他通道配置，从构建时环境变量中检索凭证。

AppStore上传的Jenkins构建配置与TestFlight构建非常相似，因为两者都需要上传到AppStoreConnect。唯一的区别是appstore通道是由Fastlane调用的，而不是由testflight通道调用的，如清单8-17所示。清单8-21显示了清单8-17中定义的构建脚本的Fastlane部分，并显示了应该对构建脚本进行的微小更改。

echo"StartingFastlane..."fastlanetestfastlanebuildfastlaneappstoreListing8-21MinorchangesrequiredforAppStorelane触发Jenkins项目将appstorelane添加到Fastfile并相应地配置Jenkins构建脚本后，可以在CodeCommit中创建新的提交，如清单8-22所示。

$gitadd.&&gitcommit-m"Uploadtoappstore"[master83fa283]Uploadtoappstore1filechanged,13insertions(+),13deletions(-)$gitpushEnumeratingobjects:7,done.Countingobjects:100%(7/7),done.Deltacompressionusingupto6threadsCompressingobjects:100%(4/4),done.Writingobjects:100%(4/4),469bytes|469.00KiB/s,done.Total4(delta2),reused0(delta0),pack-reused0Tocodecommit::us-east-1://devops-ios-repository0f80b39..83fa283master->masterListing8-22CreatingnewcommitforAppStoreupload这开始了对Jenkins的构建；清单8-23显示了AppStore上传的构建日志片段。

清单8-23。应用商店上传的Jenkins日志片段

上传的build在AppStoreConnect上可见，如图8-20所示。

图8-20

为AppStore版本上传的版本

Fastlane是一个强大的工具，有助于自动完成iOS应用开发中的许多手动任务，将该工具与Jenkins集成在一起开辟了更多的自动化可能性。在本章中，我们探讨了其中的一些可能性，并研究了如何使用Jenkins自动构建来自动测试、构建和发布iOS应用到AppStoreConnect。

本章介绍的Fastlane测试使用iOS模拟器进行测试。接下来，我们将深入使用AWSDeviceFarm在真实设备上测试AWS云上的iOS应用。

当在iOS模拟器上测试iOS应用时，您可以测试应用的功能和行为，但模拟器并不完全像真实的硬件设备一样工作，因此应用在模拟器上可能工作正常，但安装在真实的iOS设备上时表现不同。开发期间在真实的移动设备上测试iOS应用可以提高应用的质量，因为您可以模拟真实用户将如何与应用交互。

在这一章中，我们将探讨如何在AWSDeviceFarm上测试真实移动设备上的应用，并将AWSDeviceFarm与Jenkins集成，以自动化开发和测试流程。

AWSDeviceFarm有一些术语，我们在研究该服务时会用到。以下是其中一些术语及其含义:

要在AWSDeviceFarm上测试iOS应用，您需要提供从应用构建中生成的ipa应用包，还需要提供您的测试用例或使用内置测试框架，选择用于测试的物理设备，并配置将在其上测试应用的设备状态。测试后，AWS设备群生成报告；该报告的一些组成部分包括

这些报告将在AWS设备群中保留400天。

要在AWS设备场上安排测试运行，需要一个可测试的iOS应用归档文件(ipa),用于测试的ipa必须是专门为测试而构建的。

可以从Xcode生成测试应用包。可以构建一个应用进行测试，如图9-1所示。

图9-1

构建用于测试的iOS应用

构建完成后，会生成一个应用文件，可以导出并用于测试。图9-2显示了如何访问存储生成的应用档案的目录位置。

图9-2

打开生成项目位置

应用档案(带有。app扩展)应如图9-3所示进行检索。

图9-3

正在检索应用档案以进行测试

可以从图9-3中检索的应用档案中创建一个ipa档案用于设备群测试，如清单9-1所示。

如清单9-1所示，创建一个负载目录，应用文件被复制到该目录中。然后，该目录被归档并使用ipa扩展名重命名。

使用为设备群测试生成的应用ipa文件，我们将探索如何通过AWS管理控制台和AWSCLI来安排AWS设备群的测试运行。

如图9-4所示，可以从AWS管理控制台访问AWS设备群控制台。

图9-4

访问AWS设备场控制台

AWS设备场中的测试在项目中运行；可以使用现有项目，也可以创建新项目，如图9-5所示。

图9-5

创建设备场项目

AWSDeviceFarm支持多种测试框架和内置测试类型。目前对于iOS，DeviceFarm支持以下测试框架:

对于不需要您编写或维护测试脚本的内置测试类型，它提供了内置模糊。

我们将探索如何使用提供的内置模糊测试和XCTestUI测试框架在AWS设备群中运行测试。

内置模糊测试随机向设备发送用户界面事件，然后报告结果。从一个设备群项目中，可以创建一个自动化的测试运行，如图9-6所示。

图9-6

创建自动化测试运行

可以上传应用ipa档案，如图9-7所示。

图9-7

上传应用ipa

应用上传后，会显示应用的一些详细信息，也可以配置运行的名称，如图9-8所示。

图9-8

配置运行名称

接下来，我们通过选择要使用的测试框架的类型来配置测试。图9-9显示了从可用选项中选择内置模糊框架。所有默认的模糊配置都可以保持原样。

图9-9

选择内置模糊测试框架

在提供应用归档和配置测试框架之后，您可以选择测试应用的物理设备的类型。如图9-10所示，您可以使用已配置的设备池或创建自己的定制设备池。图9-10中使用的设备池是顶级设备；还显示提供的app只兼容这两款设备。

图9-10

选择设备池

您还可以配置设备状态。设备状态配置允许您选择设备语言，并配置网络选项，如Wi-Fi、蓝牙、GPS等。，适用于依赖这些设备功能的应用。这些是这个示例应用的默认设置，如图9-11所示。

图9-11

查看设备状态配置并开始运行

要查看更多详细信息并监控设备池中每个设备上运行的测试，您可以选择该测试，运行详细信息将显示出来，如图9-12所示。

图9-12

挂起状态下运行的详细信息

运行完成后，可以查看运行的状态。显示执行的测试数量及其不同的状态。饼图还显示了百分比通过和其他状态(如果适用)，如图9-13所示。

图9-13

运行的测试状态

要查看设备池中特定设备的测试报告详细信息，请选择该设备。从图9-13可以查看iPhone11和iPhoneXR的报告。在图9-14中可以看到iPhone11的示例报告。

图9-14

iPhone11的测试报告

XCTestUI框架允许您测试应用的UI功能。当您构建项目进行测试时，Xcode会生成测试包。要在DeviceFarm上使用XCTestUI框架，可以使用从清单9-1中生成的相同应用包，但是必须检索测试包并将其格式化为ipa文件，如下所示。

测试包保存在与构建工件相同的位置，可以如图9-2所示进行访问。测试包的命名模式为UITests-runner.App，可以检索图9-1中样本的测试包，如图9-15所示。

图9-15

正在检索用于测试的XCTestsUI包

可以从图9-15中检索的测试捆绑包中创建ipa档案，以实现设备群兼容性，如清单9-2所示。

$mkdirPayload&&cp-rSampleAppUITests-Runner.appPayload/$zip-rPayload.zipPayload&&mvPayload.zipXCTestUI.ipaListing9-2GeneratingipaforDeviceFarmtesting与前面生成的应用构建ipa一样，在清单9-2中，创建了一个有效负载目录，并将测试包复制到该目录中。然后，该目录被归档并使用ipa扩展名重命名。

要开始另一个测试运行，可以如图9-6所示开始创建测试运行，如图9-7所示上传appipa包。可以修改默认的测试运行名称，如图9-16所示。

图9-16

自定义测试运行名称

对于测试框架，应该从选项中选择XCTestUI。一旦选择了测试类型，上传从清单9-2创建的测试ipa包的选项也会出现，如图9-17所示。

图9-17

选择测试框架并上传测试包

一旦测试包被上传，选择测试的执行环境。应选择一个定制环境，YAML测试规范可如图9-18所示进行配置。

图9-18

配置执行环境和测试规范

测试规范包含了不同的阶段和将被执行来执行这个测试的命令。默认的YAML规范可以原样使用，但也可以修改它以添加自定义命令。

下一步是选择一个设备池来运行测试。在图9-10中，一个受管理的设备池被用于运行测试，但是让我们探索一下如何创建一个定制的设备池。通过创建自定义设备池，您可以控制选择要在其上运行测试的确切设备。

可以创建一个设备池，如图9-19所示。

图9-19

创建自定义设备池

创建自定义设备池包括为设备池提供一个名称，并选择应该在池中的移动设备。图9-20显示了一个只有一个设备的静态设备池创建示例，即iOS14.6的苹果iPhoneX。使用动态设备池，您可以创建规则，以便将符合规则的设备添加到您的设备池中。

图9-20

使用苹果iPhoneX的自定义设备池

可以选择创建的自定义设备池进行测试，如图9-21所示。

图9-21

选择自定义设备池

如图9-21所示，该设备池中只有一个设备，并且该设备与正在测试的应用兼容。其余的配置可以保留为默认，如图9-11所示开始运行。一旦创建了试运行，就可以像图9-12一样监控其状态。图9-22显示了一个完成的XCTestUI测试的例子。

图9-22

已完成XCTestUI测试

正如AWS控制台所示，首先创建一个设备场项目。创建一个项目和示例输出如清单9-3所示。

$awsdevicefarmcreate-project--nameSampleApp2--regionus-west-2{"project":{"arn":"arn:aws:devicefarm:us-west-2:123456789101:project:abcdefg2-46a7-4ebf-b3ab-7de683ad43cd","name":"SampleApp2","created":"2090-20-20T16:25:11.049000+00:00"}}Listing9-3CreatingDeviceFarmprojectwithAWSCLI用AWSCLI创建的项目也可以在AWS控制台上看到，如图9-23所示。

图9-23

在AWS控制台上查看使用CLI创建的项目

通过AWSCLI将应用上传到AWS设备群的过程分为两个步骤。首先创建一个上传，这将生成一个S3预先指定的URL，文件将被上传到这个URL。清单9-4显示了如何为清单9-3中创建的项目创建一个上传，如图9-23所示。

现在，安排运行所需的所有资源都已配置完毕。可以使用AWSCLI使用内置的Fuzz测试类型来安排测试运行，如清单9-8所示。

可以在AWSCLI上查看计划运行的状态，如清单9-9所示。

图9-24

在AWS控制台上查看的AWSCLI上计划运行

测试运行完成后，可以在控制台上查看测试报告，如图9-25所示。

图9-25

AWSCLI上计划运行的测试报告

AWSDeviceFarm可以通过其插件与Jenkinsjobs集成。通过这种集成，构建iOS应用的Jenkinsjobs可以在构建后将工件发送到AWS设备场，以便在真实设备上进行测试，而无需手动干预。

AWSDeviceFarm插件可以通过Jenkins设置页面的管理插件选项与JenkinsWebUI一起安装，如图9-26所示。

图9-26

访问Jenkins插件

可以搜索并安装插件，如图9-27所示。

图9-27

正在安装AWS设备场Jenkins插件

插件的配置包括提供AWS证书，插件将使用这些证书与您的AWS帐户中的AWS设备群进行交互。该插件支持IAM用户凭证或通过IAM角色获取临时凭证。无论使用哪种类型的IAM标识，插件都需要AWS设备场权限来提交测试运行。清单9-10显示了一个允许完整设备群访问的IAM策略示例。

{"Version":"2012-10-17","Statement":[{"Sid":"DeviceFarmAll","Effect":"Allow","Action":["devicefarm:*"],"Resource":["*"]}]}Listing9-10FullAWSDeviceFarmaccess通过将受管策略附加到插件将使用的IAM用户或IAM角色，也可以使用AWS设备场受管IAM策略。图9-28显示了附加到为设备群创建的IAM用户的AWSDeviceFarmFullAccess托管策略。

图9-28

使用AWS设备场管理策略配置的IAM用户

同样，如果使用IAM角色来配置插件，图9-29显示了使用AWSDeviceFarmFullAccess托管策略的IAM角色。

图9-29

使用AWS设备场管理策略配置的IAM角色

要配置插件，从Jenkins设置页面访问系统配置，如图9-30所示。

图9-30

访问插件配置

在“配置”页面上，滚动到“AWS设备场”部分。图9-31显示了带有IAM用户凭证的插件配置示例。

图9-31

使用IAM用户凭据配置插件

要在插件中使用IAM角色，插件假设Jenkins全局环境配置了AWS凭证，并且这些凭证将用于承担该角色。

插件IAM角色必须配置为信任Jenkins环境使用的IAM实体(用户、角色)。清单9-11显示了插件IAM角色信任关系配置的一个例子。

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":""},"Action":"sts:AssumeRole"}]}Listing9-11TrustrelationshipofthePluginIAMroleJenkins环境中用于承担插件IAM角色的IAM凭据也必须拥有承担该角色的权限。清单9-12中显示了一个IAM策略示例，它显示了如何为Jenkins环境IAM用户或角色配置权限以承担插件IAM角色。

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"sts:AssumeRole","Resource":""}]}Listing9-12ConfiguringpermissiontoassumePluginIAMrole在确保所有权限都配置为通过设备场插件使用IAM角色之后。图9-32显示了如何为插件配置IAM角色的示例。

图9-32

使用IAM角色配置设备场插件

在这一节中，我们将探讨如何将AWSDeviceFarm与Jenkins项目集成，该项目已在前一章中为自动化iOS应用构建进行了设置。将AWSDeviceFarm添加到Jenkins项目中，每当Fastlane开发一个应用时，都会自动开始设备场测试。

打开已被配置为构建iOS应用的现有Jenkins项目，并用清单9-13中所示的脚本替换构建脚本。

set+xexportTEAM_ID=`awssecretsmanagerget-secret-value--secret-idfastlane-secrets--querySecretString--outputtext|jq-r.TEAM_ID`/usr/bin/xcodebuildbuild-for-testing-schemeSampleApp-destinationgeneric/platform=iOSDEVELOPMENT_TEAM=$TEAM_IDs-allowProvisioningUpdates-derivedDataPath$WORKSPACEmkdirPayload&&cp-r$WORKSPACE/Build/Products/Debug-iphoneos/SampleApp.appPayload/zip-rPayload.zipPayload&&mvPayload.zipSampleApp.ipaListing9-13JenkinsbuildscriptforDeviceFarmtesting该构建脚本从AWSSecretsManager中检索AppleteamID，并将其配置为环境变量，构建用于使用Xcode命令行工具(xcodebuild)进行测试的应用，将构建工件保存到Jenkinsworkspace目录中，并创建一个可测试的ipa文件，以备在AWS设备场中进行测试。

在Jenkins上配置的构建脚本示例如图9-33所示。

图9-33

Jenkins上的设备场构建脚本

在构建脚本中创建的工件将被传递到AWS设备场进行测试，因此要配置AWS设备场，创建一个构建后操作，如图9-34所示。

图9-34

Jenkins后期构建操作

在后期构建操作中，选择在AWS设备群上运行测试，如图9-35所示。

图9-35

运行AWS设备场测试的生成后操作

可提供如图9-36所示的配置。应该从下拉列表中选择用于测试的项目和设备池，应该在应用选项中提供构建后ipa在Jenkins工作区中的存储路径。

图9-36

Jenkins项目上的设备场构建后配置

图9-36中的示例显示了一个ipa，它在构建后将被命名为SampleApp.ipa，并存储在工作空间的根目录中(如清单9-13中所配置的)。

Jenkins将在AWS设备场上创建的测试运行的名称也可以配置，默认情况下，build标记用于命名创建的测试运行。

还应该选择要运行的测试框架和执行环境。图9-37显示了一个使用内置模糊测试框架并在定制环境中执行测试运行的例子。

图9-37

配置测试框架和执行环境

通过在AWSCodeCommit中创建一个commit，可以在Jenkins项目上触发自动构建。您还可以在Jenkins上手动启动一个构建来测试新处理的构建后操作。

可以如图9-38所示启动手动Jenkins构建。

图9-38

开始手动Jenkins构建

清单9-14中显示了一个构建后设备群的Jenkins构建日志示例。正如所看到的，ipa文件在测试安排之前首先被上传到S3。运行也使用Jenkinsbuild标记命名。

图9-39

Jenkins项目页面上的测试状态

可以在设备群控制台上查看详细的测试报告。图9-40显示了Jenkins测试运行的报告。

图9-40

AWS设备群控制台上的测试报告

将AWS设备场测试引入iOS应用开发，可以让您模拟真实环境来运行测试和重现问题，从而提高质量和用户体验。AWSDeviceFarm可用的插件和APS也使得将它与开发工作流相集成变得可行。在本章中，我们探讨了AWSdevicefarm的主要优势，并介绍了它如何与Jenkins上的iOS开发工作流集成。

在下一章中，我们将研究本章和前面章节中涉及的所有主要开发组件是如何作为持续集成持续交付(CICD)管道中的阶段被编排在一起的。

持续集成持续交付(CICD)管道是从源代码和版本控制系统到向用户和客户交付新软件版本的软件开发步骤的自动化定义。在前面的章节中，我向iOS应用开发的不同方面和生命周期介绍了DevOps概念和工具，从构建、测试到交付。在这一章中，我将展示CICD管道如何帮助自动化和编排所有这些不同的组件到一个简化的过程中。

根据Jenkins网站的说法，“JenkinsPipeline(或简称为大写“P”的“Pipeline”)是一套插件，支持将持续交付管道实现和集成到Jenkins中。”

建立Jenkins管道的第一步是在Jenkins上创建管道。如图10-1所示，可以开始创建管道。

图10-1

建立Jenkins管道

就像前面章节中设置一个Jenkins项目一样，您可以使用CodeCommit存储库为Jenkins管道配置构建触发器，如图10-2所示。

图10-2

为管道设置生成触发器

如图10-3所示，我正在配置管道以获取管道脚本，即来自源代码提交存储库的Jenkinsfile，然后配置存储库和凭证。

图10-3

配置管道定义位置

还必须定义管道脚本在存储库中的确切位置。在本例中，管道脚本位置的配置如图10-4所示。

图10-4

配置管道脚本路径

配置好管道脚本路径后，保存管道创建即可完成创建，如图10-4所示。

如图10-4所示，必须将Jenkinsfile添加到源存储库中。图10-5显示了添加Jenkinsfile后的存储库结构。

图10-5

添加了Jenkinsfile的存储库结构

已经在Jenkins上设置了pipeline，并将Jenkinsfile添加到源存储库中，您可以通过向Jenkinsfile添加内容，开始向表示iOS应用开发过程中不同步骤的Pipeline添加阶段。首先让我们看看如何添加一个运行Fastlane测试的阶段。

清单10-1显示了一个Jenkinsfile，它定义了运行Fastlane测试的单级管道。

pipeline{agentanystages{stage("Runfastlanetest"){steps{sh"""exportLC_ALL=en_US.UTF-8&&exportLANG=en_US.UTF-8fastlanetest"""}}}}Listing10-1Single-stagePipelinedefinitiontorunFastlanetest当这些更改被提交并推送到CodeCommit时，管道触发并读取存储库中的Jenkinsfile来定义管道中的步骤。清单10-1中定义的流水线的成功执行如图10-6所示。

图10-6

Fastlane测试的单级流水线执行

此外，可以检索管道日志来查看执行和步骤的更多细节。图10-6中显示的管道执行的日志片段在清单10-2中给出。

图10-7

访问管道语法生成器

如图10-8所示，从下拉选项中选择AWS设备农场步骤。

图10-8

选择AWS设备场步骤

进入如图9-36和9-37所示的DeviceFarm测试配置(来自第九章)，并为输入的配置生成如图10-9所示的流水线脚本。

图10-9

为AWS设备场步骤生成管道脚本

应复制生成的管道脚本，并将其用于配置管道Jenkinsfile中的设备场阶段，如清单10-3所示，其中显示了将设备场阶段的配置附加到现有示例应用Jenkinsfile。

环境变量也用于TEAM_ID的那个阶段。该环境变量在管道定义的环境部分中定义。环境变量的值是在运行时从AWSSecretsManager中动态检索的。

当这些更改被提交并推送到AWSCodeCommit存储库时，管道就会触发。清单10-3中定义的流水线的成功执行如图10-10所示。

图10-10

AWS设备场测试的管道执行

测试结果也可以在AWS设备群上可视化，如图10-11所示。

图10-11

JenkinspipelineAWS设备群测试结果

当所有的应用测试都通过后，通常下一步就是构建应用。这里，我们将添加一个阶段，在Fastlane和设备场测试成功后，构建应用以供AppStore分发。

清单10-4显示了将Fastlane构建阶段附加到现有管道Jenkinsfile的代码片段。

将更改推送到AWSCodeCommit存储库后，清单10-4中定义的管道成功执行，如图10-12所示。

图10-12

应用测试和构建的流水线执行

一个成功的iOS构建意味着应用已被签名，并准备好发布以进行试飞测试或提交到AppStore。在这里，我们将向管道添加一个阶段，调用应用中配置的FastlaneTestflightlane，将应用交付给AppStoreConnect，以便使用Testflight进行beta测试。

清单10-5显示了将交付阶段附加到现有管道Jenkinsfile以将构建的工件交付到TestFlight的代码片段。

清单10-5中定义的流水线成功执行如图10-13所示。

图10-13

应用测试、构建和交付的管道执行

AWSCodePipeline是AWS的托管CICD服务。使用CodePipeline，您可以自动化软件发布过程的不同阶段，而无需担心管理管道基础设施。它还在不同阶段与不同的AWS服务和第三方工具集成，以增强软件开发，例如，它与DeviceFarm集成以进行应用测试，与GitHub集成以进行源代码控制，与Jenkins集成以进行定制构建和测试阶段。

在接下来的部分中，我将介绍如何为AWS代码管道集成准备一个Jenkins环境，然后通过演示如何在AWS代码管道上使用CICD管道运行Fastlane测试和AWS设备场测试来深入研究集成。使用将要展示的概念，您将能够扩展您的CICD管道，以覆盖更多场景。

要在AWS代码管道上配置调用Jenkins进行自定义操作的管道，必须有一个外部Jenkins服务器，并且必须配置Jenkins服务器以启用与AWS代码管道服务的交互。

让我们探讨一些完成最终目标必须具备的先决条件。

在本节中，我将使用Jenkins控制器和代理架构。请参考第四章，其中我介绍了如何提供EC2macOS服务器并连接到它，并参考第五章，其中您看到了如何在Linux和iOS上设置Jenkins控制器，并使用EC2macOS构建代理架构。

当设置成功时，在线macOS构建服务器将如图10-14所示。

图10-14

EC2macOS在线构建服务器

验证Fastlane是否安装在macOS构建代理上，如清单10-6所示。

在Jenkins构建期间，AWSCLI将用于检索存储在AWSSecretsManager中的所有Fastlane机密，因此需要在macOS服务器上安装和配置AWSCLI。

AWSCLI可以按照清单10-7中所示进行验证和配置。

$aws–-version$awsconfigureListing10-7VerifyingandconfiguringAWSCLIjq还用于在构建期间解析jSON数据，因此应该安装在macOS服务器上。可以用自制软件安装，如清单10-8所示。

$brewinstalljqListing10-8Verifyingjqinstallation设置Xcode和钥匙串访问Xcode必须使用将用于Jenkins作业的系统用户来安装和配置。

此外，确保在构建服务器上的Xcode中正确配置了应用签名。图10-15显示了在EC2Mac服务器上为将用于演示的示例应用配置Xcode签名和功能的示例。

图10-15

Xcode上的签名和功能设置

当使用Macserver作为构建代理在Jenkins上运行CICD进程时，构建通常会失败，因为在签名构建工件需要访问证书时，用户交互不可用于提供钥匙串密码。

为了防止这种情况，我将执行的步骤之一是在构建服务器钥匙串上配置签名证书，以便当Xcode在管道执行期间尝试使用它时，它允许访问而不提示输入密码。

图10-16所示的场景包括允许访问钥匙串中的证书。但是在使用“钥匙串”中的项目之前，钥匙串本身必须解锁。虽然这可以在管道执行期间自动完成，但需要钥匙串密码来解锁。在图10-17中，我将我的钥匙串密码存储在AWSSecretsManager中，这样就可以在管道运行时检索到它。

图10-17

将钥匙串密码存储在AWSSecretsManager中

图10-16

在钥匙串上配置签名证书权限

当将Jenkins与AWS代码管道集成时，Jenkins服务器必须具有与AWS代码管道服务交互的权限，以轮询作业、报告作业状态等。对于所需的权限，有一个AWS管理的策略awscodepielinecustomactionaccess包含所有所需的权限。机密也存储在AWSSecretsManager中，并在管道执行期间检索，因此必须向Jenkins服务器提供获取这些机密的权限。

当对Jenkins服务器使用EC2时，可以跨所有Jenkins节点(控制器和构建代理)使用单个JenkinsEC2IAM角色来满足权限要求。图10-18显示了JenkinsEC2IAM角色的权限配置示例。

图10-18

JenkinsEC2IAM角色的权限配置

IAM角色必须附加到所有Jenkins节点(控制器和macOS构建代理)。图10-19显示了一个将EC2IAM角色附加到现有实例的例子。

图10-19

将IAM角色附加到Jenkins实例

可以从Jenkins实例中验证附加的IAM角色。清单10-9显示了如何验证正在使用的AWS身份的示例。响应中应返回附加的IAM角色名称。

$awsstsget-caller-identity{"UserId":"AROASOKDM2HTHY4MLKGHY:i-0846273b98d6d42f4","Account":"123456789101","Arn":"arn:aws:sts::123456789101:assumed-role/ec2-mac-role/i-0846273b98d6d42f4"}Listing10-9VerifyingAWSidentityusedonJenkinsinstances正在安装AWS代码管道Jenkins插件要完成Jenkins环境设置，可以从Jenkins插件中心安装AWSCodePipelineJenkins插件，如图10-20所示。

图10-20

正在安装AWS代码管道Jenkins插件

可以通过各种方式创建管道，如AWSCLI、AWSSDKs、AWS控制台等。我将使用AWS控制台来设置管道。从代码管道控制台开始创建管道，如图10-21所示。

图10-21

从AWS控制台创建管道

对于管道设置，请提供一个名称并选择服务角色配置。在图10-22中，我选择为管道创建一个新的服务角色。

图10-22

配置管道设置

接下来是配置管道的源阶段。在图10-23中，我配置了CodeCommit存储库，示例应用代码作为源代码存储在其中。

图10-23

配置管道源阶段

在AWS控制台上创建管道时，source之后的下一阶段默认为Build，并且不能修改。此外，一个管道必须包含至少两个阶段，所以在图10-24中，我配置了一个没有实际值的临时构建阶段来解决目前的限制。

图10-24

配置临时构建阶段

有了源代码和构建阶段，我现在不需要任何进一步的阶段，所以我跳过部署阶段，如图10-25所示，继续创建管道。

图10-25

跳过部署阶段创建

创建管道后，它会自动启动。由于构建阶段被配置为没有实际值的临时阶段，因此它将失败。您可以让管道失败，也可以停止管道执行。如图10-26所示，我停止了流水线执行。

图10-26

创建后停止管道执行

既然已经建立了基本的管道，接下来，我将向您展示如何扩展这个管道，以便与Jenkins和AWSDeviceFarm集成，进行iOS应用测试。

对于这种集成，您需要首先设置一个支持CodePipeline的Jenkins项目，然后在CodePipeline上配置一个自定义stage来与Jenkins项目集成。

在这里，我将建立一个新的Jenkinsfreestyle项目，如图10-27所示，并将其配置为运行Fastlane测试。

图10-27

为Fastlane测试创建Jenkins自由式项目

由于我正在为我的Jenkins环境使用控制器和构建代理架构，我将使用如图10-28所示的标签将此构建委托给我的iOS构建代理。

图10-28

设置项目的运行位置

我们需要为源代码管理配置AWSCodePipeline，因为该项目的源代码将由AWSCodePipeline传递。我的源代码管理设置如图10-29所示。

图10-29

配置测试项目源代码管理

构建触发器调用构建。为了确保在适当的时候调用构建，我将配置项目持续轮询CodePipeline，以检查是否有任何与其配置匹配的挂起作业。如图10-30所示，我的项目将每分钟轮询一次CodePipeline中任何未完成的作业。

图10-30

为项目配置生成触发器

Fastlane测试的构建脚本如清单10-10所示。

set+xecho"Setfastlanevariables..."exportLC_ALL=en_US.UTF-8exportLANG=en_US.UTF-8echo"StartingFastlane..."fastlanetestListing10-10Fastlanetestingbuildscript该脚本应进入项目的构建命令部分，如图10-31所示。

图10-31

输入项目的构建脚本

项目配置的最后一步是添加一个AWScodepipelinePublisherpostbuild动作，如图10-32所示。提供一个工件名称来标识从Jenkins项目发布的任何工件。

图10-32

配置AWS代码管道发布者生成后操作

要将创建的Jenkins项目添加到AWS代码管道，请编辑创建的管道，如图10-26所示。删除之前配置的临时搭建阶段，添加一个新的阶段，如图10-33所示。

图10-33

删除现有的生成阶段并将新阶段添加到管道中

在新增加的阶段，增加一个新的Jenkins测试动作，如图10-34所示。

图10-34

向新阶段添加新的Jenkins测试行动

配置Jenkins测试操作。在配置Jenkins项目时，可以从提供和记录的值中检索提供者名称、项目名称和输出工件字段。在服务器URL字段中，输入Jenkins控制器的公共IP地址。图10-35显示了我的Jenkins测试动作的配置。

图10-35

配置Jenkins测试操作

一旦配置了操作，您现在将拥有一个两阶段管道。要开始管道执行，您可以将新提交推送到CodeCommit存储库，或者在CodePipeline控制台上手动发布更改。

图10-36显示了Fastlane测试的成功管道执行。

图10-36

Fastlane测试的成功管道执行

关于Jenkins项目执行的更多信息，可以从Jenkins获取构建日志。清单10-11显示了在Jenkins上为图10-36所示的管道运行生成的日志片段。

清单10-11。Fastlane测试代码管道执行的日志片段

将真实iOS设备上的测试添加到您的开发过程中是势在必行的，我将演示如何将AWS设备场测试的阶段添加到现有的CICD管道中。类似于之前配置的Fastlane阶段，我将首先设置一个支持代码管道的Jenkins项目来构建应用，之后我将设置一个用于测试的AWS设备场项目，然后最后在代码管道上配置一个设备场阶段，并使用与Jenkins和AWS设备场集成的单独操作。

要在DeviceFarm上测试iOS应用，需要ipa包。这里创建的项目将用于生成可测试的ipa包，以供设备场使用。

这需要创建一个新的Jenkinsfreestyle项目，如图10-27所示。我还将确保这个项目在我的iOS构建代理上运行，如图10-28所示。对于源代码控制管理，虽然它与之前创建的项目相似，但我会更改一些字段以适应当前的用例，如图10-37所示。

图10-37

配置生成项目源代码管理

在图10-37中，CodePipeline动作类型类别被设置为build，因为该项目被配置为Build动作，并且它将在CodePipeline上被配置为Build动作。

这个项目的构建触发器将像之前为Fastlane测试创建的项目一样进行配置，如图10-30所示。

清单10-12中显示了将用于这个项目的构建脚本。

set+xexportTEAM_ID=`awssecretsmanagerget-secret-value--secret-idfastlane-secrets--querySecretString--outputtext|jq-r.TEAM_ID`exportKEYCHAIN_PASSWORD=`awssecretsmanagerget-secret-value--secret-idfastlane-secrets--querySecretString--outputtext|jq-r.KEYCHAIN_PASSWORD`security-vunlock-keychain-p"$KEYCHAIN_PASSWORD""$HOME/Library/Keychains/login.keychain"/usr/bin/xcodebuildbuild-for-testing-schemeSampleApp-destinationgeneric/platform=iOSDEVELOPMENT_TEAM=$TEAM_ID-allowProvisioningUpdates-derivedDataPath$WORKSPACEmkdirPayload&&cp-r$WORKSPACE/Build/Products/Debug-iphoneos/SampleApp.appPayload/zip-rPayload.zipPayload&&mvPayload.zipSampleApp.ipaListing10-12Appbuildfortestscript如构建脚本所示，团队ID和钥匙串密码是从AWSSecretsManager中检索的。在构建应用以使用xcodebuild进行测试之前，钥匙串密码用于解锁钥匙串。

脚本应该进入项目的构建命令部分，如图10-38所示。

图10-38

项目配置的最后一步是添加一个AWScodepipelinePublisherpostbuild动作，如图10-39所示。提供一个工件名称来标识从这个Jenkins项目发布的任何工件。

图10-39

我将使用在第九章中创建的设备农场项目。将使用的项目如图10-40所示。

图10-40

AWS设备场项目

要提交测试运行，您还需要有一个设备池。在本例中，我将使用托管的“顶级设备”设备池来测试我的应用。为了从AWSCodePipeline中使用这个设备池，我必须提供设备池ARN，因此为了获得ARN，使用可以从图10-40中检索的项目ARN，我将使用清单10-13中所示的AWSCLI。

$awsdevicefarmlist-device-pools--arnarn:aws:devicefarm:us-west-2:123456789101:project:3973dab9-33ab-4d34-87c6-3e183e009b07--regionus-west-2--query'devicePools[name==`TopDevices`]'Listing10-13GettingdevicepoolARN将设备场阶段添加到管道我已经配置了一个Jenkins项目，它可以构建我的测试应用并生成工件，我还有一个设备场项目可供使用。现在，我将向管道中添加一个新的阶段。

编辑管道并添加新阶段，使其成为三阶段管道。图10-41显示了我给新舞台起的名字。

图10-41

添加设备场阶段

添加新阶段后，您将配置第一个操作。这将是一个Jenkins构建操作，它将连接到之前创建的Jenkins项目。图10-42显示了如何添加一个Jenkins构建动作。

图10-42

添加Jenkins构建操作

提供者名称、项目名称和输出工件字段可以从配置Jenkins项目时提供和记录的值中检索。在服务器URL字段中，输入Jenkins控制器的公共IP地址。图10-43显示了我的Jenkins构建动作的配置。

图10-43

配置Jenkins构建操作

接下来，在同一阶段，我们将配置设备场操作。设备场操作不能与Jenkins操作并行运行，因为设备场依赖于Jenkins操作生成的工件。可以添加一个新的动作组，如图10-44所示。

图10-44

添加设备场操作

设备农场动作可以如图10-45所示进行配置。应该选择AWS设备场作为测试提供程序。Jenkins操作中配置的输出工件必须配置为该操作中的输入工件，以便工件可以交换。此处应提供从设备场检索的项目ID和设备池ARN。AppType、输入工件中ipa文件的路径和TestType也是必填字段。

图10-45

配置设备场操作

配置完这两个动作后，您应该有一个如图10-46所示的阶段。

图10-46

配置了两个操作的设备场阶段

一旦配置了操作，您现在将拥有一个三级管道。要开始管道执行，您可以将新提交推送到CodeCommit存储库，或者在CodePipeline控制台上手动发布更改。

图10-47显示了Fastlane测试和AWS设备群测试的成功流水线执行。

图10-47

Fastlane测试和设备群测试的流水线执行

可以从Jenkins检索应用构建的构建日志，同时可以从设备群控制台查看设备群测试结果的详细信息。

CICD管道使您能够协调应用开发的不同步骤和组件，从源代码控制到用户部署。在这一章中，我用真实的例子展示了不同风格的CICD管道，比如Jenkins管道和AWSCodePipeline，是如何被用来编排我们在前面章节中涉及的不同概念的。

在JenkinsPipeline中，我们看到了如何测试、构建应用并将其交付到AppStoreConnect。在AWSCodePipeline中，我们涵盖了不同的测试选项，同时还集成了Jenkins。AWSCodePipeline可以进一步扩展，以添加额外的阶段，如JenkinsPipeline。例如，在设备场测试后，您可以添加一个额外的阶段，与Jenkins集成以构建一个应用，用于与Fastlane一起分发，甚至将应用交付到AppStoreConnect。