はじめに
前提として、このブログの内容を踏まえたものです。
上述のブログの言を借りると、AWS CodeCommitにおいて7/28現在、以下の状況になっている様子です。
- 既存リポジトリがあるアカウントは特に制限無くCodeCommitを利用可能
- これまでCodeCommitを使っていなかったアカウント(もしくは既存リポジトリが無いアカウント)は新規リポジトリ作成不可
これはCodeCommitのサービス終了を即座に意味するものではありません。ただし、リポジトリを新規に利用できなくなるということは、一般的にはCodeCommitとしてのサービス縮退、メンテナンスフェーズとして捉えることもできます。先のブログが公開されたのは日本時間では土曜日ということもあり、少なくともこの解釈を否定するアナウンスは出ておらず、個人的には動揺する点もありました。
今回はCodeCommitが担っていた役割を振り返りながら、今後の新規アカウントで使えなくなる場合の影響や、移行時に気になる点を可能な限り整理します。
2024/07/31 追記
本文記載のAWS re:Postでのアナウンスについては、現時点では削除されています。
同タイミングで、Jeff Barrのツイートにより以下の見解が示されました。
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に関わる一般的な説明は、例えばこの辺りが参考になるでしょう。
エンジニア目線で見た時のCodeCommitは、正直いって嫌々使うものだったかもしれません。他者のGitサービスに比べて目立った長所のようなものはなく、どちらかというと不足する機能で困らされることもありました。
個人的に辛かった点として、以下が思い出されます。
-
レビュー機能が貧弱。UI的な細かい部分もさることながら、コード部分の表示制限で数千行以上のものが表示されず、GUIベースの円滑なレビューが難しい。
- この記事によると3250行が閾値の様子
-
CodeBuildとのブランチベースの連携が不足している
- この記事で触れられているように、
feature/*などワイルドカードを使った発火設定をネイティブに実装することが難しい。
- この記事で触れられているように、
管理者としてのCodeCommit
ここまでを読むと極端な話、別に無くなっても困らないサービスなのでは？という感想を持たれそうな気もしますが、特にエンタープライズ利用から見た時に、有意な点は確かにありました。少なくとも私は下記の理由で利用していました。
- GitサービスをAWSのエコシステムとして扱える
- 提供事業者が同じ
- リポジトリ管理における「チームでの手の内化」
CodeCommitのあまり語られないメリットについて紹介します。
メリット1. GitサービスをAWSのエコシステムとして扱える
CodeCommitは以下の機能を持っている唯一のGitサービスです。
- IAMベースの認証
- VPCエンドポイント経由のVPC連携
- EventBridge経由のイベント連携
つまり、Gitリポジトリの運用もAWSのエコシステムで統一する目的で、CodeCommitを採用していた場合には影響を受けてしまうとも言えます。
メリット2．提供事業者が同じ
メリット1と同じに見えるのですが、事業者が同じであることで契約の一本化ができていました。
企業内利用で考えると、経理や監査部門との調整などをAWSのエコシステムという理由で緩和していた方は影響を受けてしまうとも言えます。
この決済一本化に関してはCodeCatalystでもある程度代替えはできます。とはいえ、メリット1で上げた点や、CodeCatalystのリージョンがオレゴンのみである点(＝リポジトリを国内リージョンに作成できない)への考慮が必要です。
メリット3. リポジトリ管理における「チームでの手の内化」
GitHub Enterpriseなどを全社で利用している場合、例えばAWSアカウントと管理者が異なり、組織間をまたぐリポジトリの払い出しにタイムラグがあるシチュエーションも起こりえるでしょう。
ガバナンスと表裏な部分もありますが、CodeCommitの場合はAWSの一定のIAM権限があれば利用できるため、GitOpsがクイックに進められる点もありました。
CodeCommitが使えなくなると何が困るか
ここまでの話をまとめるとCodeCommitが使えなくなると何が困るか、という点が見えてきます。
- アプリケーション開発者としてはそこまで困らないかもしれない
- インフラ管理として、困るシチュエーションが存在しうる
- AWS連携
- 会計一本化
- リポジトリ管理
皆さんはどうでしょうか？ ここに書いてないような事例や観点があればぜひぜひ教えてください。
私とCodeCommit
あくまで個人的な見解ですが、CodeCommitは3rd PartyのGitサービス採用が、何らかの理由で難しい時の切り札(最終手段？)として捉えていました。機能として気になる点は確かにあったものの、プロジェクトごとにGitのセルフホスティングを行うのは、可用性や運用面であまり現実的ではないと考えるためです。
とはいえこのような考え方はマイナーというか、あまり多くないのかもしれません。私は業務で2023年にCodeCommitを採用したことがあったので驚いているのですが、AWS re:Postにもあるように、新規リポジトリが作成できない件は2024/06/06からだった様子です。にも関わらず、これといったナレッジが出ていないということは、縮退してもおかしくない利用率だったのかもしれませんね……
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などが基本になるでしょう。
特にGitHubはシェアも大きいですし、体感的にもうまく回るように思えます。また、明に触れられていないのが気になりますが、CodeCatalystでもリポジトリを作成することは可能です。
とはいえ、以下のような落とし穴もあるようですので、CodeCommitからの移行時には検討は必要です。特にCodeCatalystは既存のCodeシリーズとの統合があまり進んでないように見受けられる点にも注目です。
-
Codeシリーズとの連携状況
-
CodeBuildの連携対象にCodeCatalystが含まれていないことに注意。
-
CodePipelineの連携対象にCodeCatalystが含まれていないことに注意。
-
CodeGuru Reviewer/Securityの連携対象にCodeCatalystが含まれていないことに注意。
-
CodeGuru Profilerについては情報を持っていないため割愛
- 情報あればコメントまでお願いします。
-
-
一部サービスにて、連携の難しいものがある。
- 例として、GlueとGitHub Enterpriseの連携ができていない？
-
GitHubと連携時の権限管理スコープの検討
- 例として、こちらの書き込みのようなケース
まとめ
CodeCommitがメンテナンスモードになってしまう、という仮定で総括と移行について書いたのですが、後継サービスが登場するなど、あまり問題にならない結果となるといいですね。それでは。