前言
截至7月28日，关于AWS CodeCommit的现状如下：
- 现有账号的现有存储库可以继续使用CodeCommit，不受限制。
- 之前未使用过CodeCommit的账号（或没有现有存储库的账号）无法创建新的存储库。
这并不意味着CodeCommit的服务会立即终止。然而，无法创建新存储库这一事实一般可以理解为CodeCommit服务的缩减和进入维护阶段。由于该博客的发布是在日本时间的周六，至少目前还没有任何官方声明否定这一解读，个人对此感到有些不安。
本文将回顾CodeCommit所承担的角色，并尽可能整理在新账号无法使用时的影响以及在迁移过程中需要注意的事项。
After giving it a lot of thought, we made the decision to discontinue new access to a small number of services, including AWS CodeCommit.
While we are no longer onboarding new customers to these services, there are no plans to change the features or experience you get today,
We also support migrations to other AWS or third-party solutions better aligned with your evolving needs. Keep the feedback coming. We’re always listening.
作为开发者的CodeCommit
从工程师的角度来看，CodeCommit可能是一个不情愿使用的工具。与其他Git服务相比，它并没有明显的优势，相反，缺少的一些功能常常让人困扰。
以下是我个人觉得比较辛苦的几点：
-
代码审查功能贫弱：不仅在UI方面存在一些细节问题，而且在代码部分的显示上也有很多限制。例如，当代码超过几千行时就无法显示，这使得基于GUI的顺畅审查变得困难。
-
与CodeBuild的分支联动不足：例如，像文章中提到的，使用feature/*等通配符进行触发设置在CodeCommit中难以实现。
作为管理者的CodeCommit
读到这里，可能有人会觉得即使CodeCommit消失了也不会有太大影响。然而，从企业用户的角度来看，它确实有一些显著的优势。至少，我出于以下几个原因选择了使用CodeCommit。
-
将Git服务作为AWS生态系统的一部分：CodeCommit是唯一具有以下功能的Git服务：
- 基于IAM的认证
- 通过VPC端点进行VPC集成
- 通过EventBridge进行事件集成
换句话说，如果采用CodeCommit是为了统一AWS生态系统中的Git存储库操作，那么其消失将会带来影响。
-
提供商相同：这一点看起来与第一点类似，但由于提供商相同，可以简化合同管理。
从企业内部使用的角度来看，与财务或审计部门的协调因为AWS生态系统而变得简单。如果CodeCommit消失，这些部门将会受到影响。虽然CodeCatalyst可以在一定程度上替代这一功能，但考虑到CodeCatalyst目前仅在俄勒冈地区提供服务（即无法在国内区域创建存储库），仍需对此进行权衡。
-
存储库管理中的“团队内部控制”：如果整个公司使用GitHub Enterprise等服务，例如，AWS账户和管理员不同，跨组织的存储库发布可能会存在时间延迟。
虽然这在某种程度上与治理有关，但在CodeCommit的情况下，只要拥有一定的IAM权限就可以使用，因此GitOps可以迅速推进。
如果不能再使用CodeCommit，会带来哪些困扰？
总结到这里，我们可以看出如果不能再使用CodeCommit，可能会带来以下几个困扰：
-
对应用开发者来说，影响可能不大：由于应用开发者可以选择其他Git服务来替代，功能上也能满足大部分需求，因此他们可能不会受到太大困扰。
-
对基础设施管理来说，可能会遇到一些困扰：
-
AWS集成：CodeCommit与AWS的其他服务（如IAM认证、VPC集成和EventBridge事件集成）紧密结合，如果转移到其他Git服务，这些集成将需要重新配置，增加了工作量和复杂性。
-
会计合同的统一管理：由于CodeCommit和其他AWS服务来自同一提供商，这简化了合同管理。如果切换到其他Git服务，需要处理多个供应商的合同，增加了管理难度。
-
存储库管理：使用CodeCommit，团队可以利用AWS IAM权限进行快速且高效的存储库管理。如果切换到其他服务，可能会遇到跨组织协调和发布延迟的问题。
-
大家怎么看呢？如果有其他未提到的案例或观点，请务必分享。
我和CodeCommit
这只是我的个人看法，但我一直认为CodeCommit是当因某些原因难以采用第三方Git服务时的最后一张王牌（最终手段？）。虽然它确实存在一些功能上的不足，但我认为，对于每个项目都进行Git自托管在可用性和运营方面并不现实。
尽管如此，这种想法可能并不多见。我在2023年的工作中曾经采用过CodeCommit，所以对这个变化感到非常惊讶。根据AWS repost
的信息，无法创建新存储库的情况从2024年6月6日开始生效。然而，尽管如此，却没有出现相关的知识分享，可能意味着即使服务缩减了，也不会有太大的使用影响吧……
Beginning on 06 June 2024, AWS CodeCommit ceased onboarding new customers. Going forward, only customers who have an existing repository in AWS CodeCommit will be able to create additional repositories.
迁移候选
作为CodeCommit的迁移候选，如下博客中所述，GitHub和Gitlab等将是基本选择。
迁移候选
作为CodeCommit的迁移候选，如下博客中所述，GitHub和Gitlab等将是基本选择。特别是GitHub，其市场份额大，使用体验也很好。此外，虽然文中没有明确提到，但CodeCatalyst也可以用于创建存储库。
然而，需要注意以下潜在的陷阱，在从CodeCommit迁移时需要加以考虑。特别是CodeCatalyst与现有Code系列的整合似乎并不完善。
与Code系列的整合情况
-
CodeBuild：请注意，CodeCatalyst未包含在CodeBuild的整合目标中。
-
CodePipeline：请注意，CodeCatalyst未包含在CodePipeline的整合目标中。
- CodeStarSourceConnection for Bitbucket Cloud, GitHub, GitHub Enterprise Server, GitLab.com, and GitLab self-managed actions - AWS CodePipeline
-
CodeGuru Reviewer/Security：请注意，CodeCatalyst未包含在CodeGuru Reviewer/Security的整合目标中。
- Getting started with CodeGuru Security - Amazon CodeGuru Security
总结
基于CodeCommit进入维护模式的假设，本文对其进行了总结，并探讨了可能的迁移选项。希望未来会有新的继任服务出现，使这一问题变得不再棘手。
谢谢阅读！
标签：存储,Git,服务,CodeCatalyst,AWS,CodeCommit,复盘,移行 From： https://blog.csdn.net/rralucard123/article/details/140964645