Kanji
・云架构工程师 / 自由职业 ・1993年出生 ・爱媛县出身 / 现居东京都涩谷区 ・5年 AWS 实战经验 个人资料详情
目录
根据官方用户指南，AWS CodePipeline 定义如下：
<块引用> AWS CodePipeline 是一项持续交付服务，您可以使用它对发布软件所需的步骤进行建模、可视化和自动化。 您可以快速建模和配置软件发布过程的不同阶段。 CodePipeline 自动执行持续发布软件更改所需的步骤。
来源： 什么是 AWS CodePipeline？- AWS CodePipeline
根据官方用户指南，AWS CodeCommit 的定义如下：
<块引用> AWS CodeCommit 是由 Amazon Web Services 托管的版本控制服务，您可以使用它来私密存储和管理资产 （例如文档、源代码和二进制文件）在云中。
来源： 什么是 AWS CodeCommit？- AWS CodeCommit
根据官方用户指南，AWS CodeBuild的定义如下：
<块引用> AWS CodeBuild 是一项完全托管的云构建服务。 CodeBuild 编译源代码、运行单元测试并生成可供部署的工件。 CodeBuild 无需配置、管理和扩展您自己的构建服务器。 它为流行的编程语言和构建工具（例如 Apache Maven、Gradle 等）提供预打包的构建环境。 您还可以在 CodeBuild 中自定义构建环境以使用您自己的构建工具。CodeBuild 可自动扩展以满足峰值构建请求。
来源： 什么是 AWS CodeBuild？- AWS CodeBuild
根据官方用户指南，AWS CodeDeploy 的定义如下：
<块引用> CodeDeploy 是一项部署服务，可自动将应用程序部署到 Amazon EC2 实例、本地实例、无服务器 Lambda 函数或 Amazon ECS 服务。
您可以部署几乎无限种类的应用程序内容，包括：
来源： 什么是 CodeDeploy？- AWS CodeDeploy
根据官网，GitHub的定义如下：
<块引用> GitHub 是一个受用户想法启发的开发平台。通过在 GitHub 上托管源代码， 从开源项目到商业使用，您可以与数百万其他开发人员一起审查代码、管理项目并共同开发软件。
来源： GitHub 日本 |GitHub
CI/CD 管道管理的资源候选包括应用程序源代码、基础设施即代码 (IaC) 以及构建和部署应用程序所需的配置文件。使用这些资源部署的应用程序和基础设施必须通过 CI/CD 管道作为代码进行管理，不仅在开发期间而且在运营期间。考虑CI/CD管道管理的资源是否可以作为代码进行管理，同时考虑到开发人员和运维人员的技能和操作。例如，考虑从 CI/CD 管道管理中排除以下情况：
CI/CD 管道管理的代码资源在 AWS CodeCommit 或 GitHub 等存储库服务中进行管理。AWS CodeCommit、AWS CodePipeline、AWS CodeBuild 和 AWS CodeDeploy 是 AWS 提供的服务，如果没有现有的用于管理代码资源的存储库服务，AWS CodeCommit 将是第一个候选。但是，如下所示，AWS CodeCommit 将自 2024 年 7 月 25 日起停止接受新客户。
<块引用> 经过慎重考虑，我们决定自 2024 年 7 月 25 日起停止接受 AWS CodeCommit 新客户。使用 AWS CodeCommit 的现有客户可以继续照常使用该服务。AWS 将继续投资于 AWS CodeCommit 的安全性、可用性和性能，但没有计划推出新功能。
来源（日语翻译）： 如何将您的 AWS CodeCommit 存储库迁移到另一个 Git 提供商 |AWS 开发运营和开发人员生产力博客
目前尚不清楚 AWS CodeCommit 将来何时不可用，因此，如果您尚未使用 AWS CodeCommit，建议使用其他存储库服务来管理您的代码资源。与数据库相比，迁移难度并不高，但一旦开始使用某个服务，迁移到另一个服务就很难了。考虑内部规则、可用功能、安全要求和未来前景，仔细选择服务。
在某些情况下，使用 CI/CD 管道将相同的代码部署到多个环境或资源，例如：
为了解决这些问题，可以使用以下方法：
下面对每种方法进行解释。
如果您采用 GitHub Flow 或 git-flow 等分支策略，则可以针对开发、登台和生产等多种环境使用不同的分支。例如，您可以使用主分支进行生产，使用开发分支进行暂存，使用功能分支进行开发。在这种情况下，您可以运行由每个分支的更新触发的 CI/CD 管道并部署到每个环境。由于开发人员可以自由命名和使用功能分支，因此需要 CI/CD 管道的动态执行。例如，AWS Prescriptive Guidance 引入了以下模式：
使用 AWS Service Catalog 和 AWS CodePipeline 自动化动态管道管理以将修补程序解决方案部署到 Gitflow 环境 - AWS Prescriptive Guidance
这样做的好处是，通过检查分支的内容，您可以轻松查看哪些代码部署到了哪个环境。
缺点是随着分支数量的增加，CI/CD管道的数量也随之增加，管理变得更加复杂。此外，由于分支流程往往变得复杂，对于 Git 熟练程度较低的开发人员来说，分支管理可能会很困难。
此方法使用单个分支部署到多个环境或资源。例如，当主分支更新时，可以将相同的代码一次性部署到开发、暂存和生产环境中。
优点是减少了分支数量，使 CI/CD 管道管理更容易。
缺点是，由于相同的代码一次部署到所有环境，因此很难进行分阶段部署，例如先部署到开发环境进行测试，然后再部署到分阶段和生产环境。
建议在部署安全或监控服务等基础设施资源（而不是应用程序资源）时使用此方法。
此方法使用手动作业来重用构建/部署工件并部署到多个环境或资源。例如，您可以重用部署到开发环境的应用程序的构建工件，并将它们部署到临时或生产环境。在这种方法中，您可以在执行CI/CD管道后，通过手动运行作业来部署到所需的环境或资源。
优点是您可以通过重用构建/部署工件将相同的代码部署到多个环境或资源。此外，您只需要准备同时运行作业所需的 CI/CD 管道，因此可以减少 CI/CD 管道的数量。
缺点是在运行 CI/CD 管道并生成构建/部署工件后，您需要手动运行作业，这可能会增加分阶段部署所需的工作量。
根据您构建 CI/CD 管道机制的程度，您可以构建高度通用的 CI/CD 管道。
CI/CD管道中用于管理资源的主要工具如下：
使用这些部署和构建/静态分析工具，您可以对 CI/CD 管道管理的资源进行部署、构建和执行静态分析。
注意：仅仅因为这些工具自动执行构建/部署过程并不意味着您不需要学习这些工具。 通过建立操作过程中更改参数文件的流程，可以减少工具的学习成本，但在开发过程中，您将需要学习工具，因为您可能需要在自己的环境中构建/部署以进行故障排除，而不仅仅是通过 CI/CD 管道。选择要在 CI/CD 管道中使用的工具，同时考虑开发人员的技能和操作要求。
一旦决定了工具，请考虑 CI/CD 管道的步骤。
如何考虑这些步骤正在准备中。
一旦决定了 CI/CD 管道中使用的工具，请确定这些工具管理的资源、其管理员和部署目标。例如，如果您使用 AWS CLI (CloudFormation) 部署 AWS 资源，请按如下方式组织：
组织时，重要的是要明确哪个团队管理哪些资源以及这些资源的部署位置。对于每个托管资源，请在下一节“4. 存储库分段单元”中考虑由哪个存储库来管理它。
考虑如何将 CI/CD 管道管理的资源分段到代码存储库中。细分视角包括以下内容：
基本上，通过“1.功能”细分，还可以同时按“2.管理员”和“4.生命周期”细分。如有必要，请考虑在“1.功能”中进一步细分“4.生命周期”。例如，在对网络防火墙进行分段时，通过将资源分为初期建设部署和运营部署，可以避免防火墙本身被删除的风险。在这里，更详细地组织“托管资源”。
对于“3.部署目的地”，考虑如何根据前面讨论的“1.如何部署到多个环境/资源”的结果进行分段。例如，对于 GuardDuty，您可以按共享帐户和每个环境帐户进行细分，如下所示：
为每个分段代码存储库构建 CI/CD 管道时，请为每个 CI/CD 管道设置权限。首先整理一下每个管理员哪些权限是不能授予的，然后再考虑进一步限制权限。例如，如果有三个团队：平台团队、开发团队、运营团队，则可以按如下方式设置权限：
重要的是不要将 CI/CD 管道权限限制得太细。如果权限限制过多，CI/CD 管道可能缺乏运行所需的权限，从而导致部署失败。此外，由于您可以使用拉取请求或批准阶段来限制 CI/CD 管道本身的执行，因此不建议严格限制权限作为针对内部欺诈的对策。如果您确实进行限制，建议使用以下 AWS 托管策略来授予必要的权限。
AWS 托管策略 - AWS 托管策略