CodeCommit廃止により、GitHubを導入した件

technologies

おはようございます!ベンジャミンの木村です!

7月25日(木)AWSより以下のような報告がありました。

慎重に検討を重ねた結果、 2024 年 7 月 25 日をもちまして、 AWS CodeCommit について、新規のお客様向けのアクセスを閉じることを決定いたしました。 AWS CodeCommit を既にお使いのお客様は、これまで通りサービスをご利用いただくことが可能です。 AWS は AWS CodeCommit のセキュリティ、可用性、パフォーマンスの改善に引き続き投資を行ってまいりますが、新機能の導入は予定しておりません。

AWS CodeCommit リポジトリを他の Git プロバイダーに移行する方法

「何だって!?今後、CodeCommitが新規アカウントで使えない!?」

弊社としても、ほぼほぼ全ての案件でCodeCommitでコード管理をしていたので、衝撃の報告でした。

今回、CodeCommitの代わりに他のGitツールを検討し、GitHubを選定しましたので、その過程を報告させていただきます。

1. CodeCommitは何がいいだっけ?

弊社でCodeCommitを使っていた理由としては、以下の点になります。

  1. セキュリティ
  2. コスト
  3. コード譲渡のしやすさ

それぞれの観点として、詳細に説明させていただくと下記になります。

セキュリティ観点

内部ネットワークでの連携:
CodeCommitはVPCエンドポイント経由で他のAWSサービスとアクセスが可能で、トラフィックがインターネットを経由せずに、AWSの内部ネットワークを通じて直接通信できます。そのため、データ漏洩のリスクが減少します。

※GitHubでは通信の暗号化は行われていますが、AWS内部での閉ざされた連携操作はできなくなります。なので、完全にAWSで閉じられた操作が必要な場合はCodeCatalystを検討する必要があります。CodeCatalystは比較的新しいサービスなので、まだ情報少ないですが、今後要件によっては、検討していきたいとも考えています。

IAM統合によるアクセス制御:
CodeCommitはIAMにより詳細なアクセス制御ポリシーを設定することが可能です。それにより、例えば、特定のユーザーに対してリポジトリへのアクセス権を制限することができます。

※GitHubではIAMを用いた厳密な権限操作はできなくなりますが、ブランチの保護機能によって、特定のBranchへの直接push禁止や、特定ブランチへのマージの際に承認を強制するなど、運用上問題ない程度までの権限操作が可能です。

監査とログ記録の統合:
CodeCommitでのすべての操作はAWS CloudTrailに記録され、監査ログを残すことができます。これにより、誰がいつ何を行ったかを追跡することができます。

※Githubにも同様の監査ログの設定を行うことができます。

コスト観点

無料利用枠の提供:
CodeCommitは、最初の5ユーザーまで無料で利用できます。各アカウントで5ユーザーまでなので、ほぼ無料枠で運用することが可能です。また、6ユーザー以降も1ユーザーあたり1 USD/月なので、ほぼコストはかかりません。

追加コストが発生しない:
CodeCommitはリポジトリの数に制限がなく、追加のリポジトリやユーザーを追加しても予期せぬコスト増加が発生しにくいです。

※「AWS CodeCommit の料金」より参照

※この後説明しますが、GitHubに移行することで、チームで使う場合は、コストが$4/user・月発生します…

コード譲渡のしやすさ

クライアントへの円滑な移行:
弊社のような受託会社ならではですが、プロジェクトの完了時や契約終了時にクライアントへコードを譲渡することがよくあります。CodeCommitを利用することで、AWSアカウント譲渡と同時にコードが譲渡されるため、クライアントへの引き渡しがスムーズに行えます。

※GitHubだと相手がGitHubを使っている場合はフォークや、リポジトリの譲渡は可能ですが、使っていない場合は、ローカル上に落としたコードを渡すか、クローンしてもらう操作が必要になります…

2. 各社Git管理ツールの比較

それでは、CodeCommitの利点について理解していただいたところで、「他のGitツールはどうなの?」「何でGitHubにしたの?」という点について説明させていただきます。

弊社としてCodeCommitがなくなり、一番困った点は「権限管理」というところでした。

文化やルールの違う海外エンジニアや、アプリとインフラといった専門性の違うエンジニアと働くこともあります。また、リーダーとエンジニア1年目といった知識幅の違うエンジニアと働いたり、さらには社外の協力会社と一緒に働くこともあります。

立場や知識の違うエンジニアと働く場合、「権限管理」は必須の要件となります。

その観点で、色々なGitツールを比較した結果下記のような調査結果となりました。

CodeCommitBitbucket
(Premium)
GitLab
(Premium)
Github
(Team)
コスト5 userまで無料
※6人目から1 USD/月
6 USD/月・user29 USD/月・user$4/月・user
権限操作・きめ細かい権限操作が可能・きめ細かい権限操作が可能・Mainブランチへの直接push禁止
・プルリクエスト/承認フローを制御可能
・Mainブランチへの直接push禁止
・プルリクエスト/承認フローを制御可能
その他
メリット
・作成範囲がアカウント内なのでお客様への受け渡しが簡単
・コストが安い
・権限がIAM Policyで細かく設定可能

・ATLASSIAN社が提供しているソフトと連携しやすい
・CICDが簡単に設定可能
・包括的なDevOps機能
・使い慣れているエンジニアが多い
・自動セキュリティ管理機能がある
その他
デメリット
・環境がアカウントで跨る場合、クロスアカウントの複雑な設定が必要・使用ユーザーが少ない・コストが高すぎる・権限操作が他と比べて厳しくできない
※ブランチの権限操作が可能な有料プランを抜粋しています

弊社としては、これらを比較し、一番必要だった権限操作がある程度問題なく使えて、かつコストが一番安く、使い勝手がいいという理由からGitHubを選定しました。

3. CodeCommitからGithubへの移行してよかった点

今回弊社はCodeCommitからGitHubに移行しましたが、「移行してみてGitHubて良かったの?」という点についてCodeCommitと比較しながら説明させていただきます。

私が「これは良い!」と感じた点は以下の4つです。

GitHubの利点CodeCommitと比較して
他のAWSリソースとの連携アカウント依存がないので、複雑な設定なしに、CodePipeline、Amplifyともに問題なく連携可能。CodeCommitだとクロスアカウント設定が必要になる場面が多かった。
パッケージの依存関係管理Dependabotによって、脆弱性のあるパッケージのアラートを自動で出してくれる。
また、バージョンアップのPull Requestも提案してくれる。
CodePipelineからCodeArtifactと連携する必要がある。
(CodeCommitの段階ではパッケージの脆弱性に気付けない)
権限管理各リポジトリに、各ユーザーに対して設定可能。
→CodeCommitと同様の厳しいブランチ権限はつけれない点は気になる点…
各IAMユーザーのに割り当てられる。
→より厳しい権限操作が可能だが、インフラ側で操作が必要
プロジェクト管理機能Issueの記載や、GitHub Projectsを用いいてガントチャート、Todoリストが使える。そういった機能はなし。

これにより、GitHubは使い勝手が良く、アプリケーション側での管理やプロジェクト管理を重視する場合に優れた選択肢となると感じました。

私が特に良いと感じたのは、アカウント依存がない点Dependabotの使い勝手です。

4. Github Teamプランでできること

ここまで、GitHubへの移行の説明をしましたが、今まで全くGitHubを使ってなかったというわけではありません。特定の要件のみGitHubの無料プランで運用しておりました。

ただ、CodeCommitが廃止になるということで、せめて「チームごとにブランチの権限操作はほしいな〜」という要件からGitHubを有償のTeamプランに引き上げました。

そこで、Teamプランに変更することにより、GitHubではどんなことができるようになるの?という点を説明させていただきます。

説明
GitHub Codespace統合開発環境をGithubで操作可能なもの。 コンピューティング料金は1時間あたり0.18ドルから、ストレージ料金は1GBあたり毎月0.07ドルになる。
Github Actionの利用可能時間増加2,000分/月 → 3,000分/月に変更
Github Packages独自のソフトウェアパッケージをホストしたり、他のプロジェクトの依存関係として使用することができる。
ブランチ保護特定のブランチのマージへの制限や直接pushの禁止などが行える。
Pull Requestの承認者のアサイン複数のユーザまたはTeamにPull Requestのレビューをアサインできる。
定期リマインダー指定した時間にメッセージの送信ができる
Issueをチームで管理1つのIssueに複数人をアサインできます。 →Projects機能を使うと、IssueをTodo形式で使用することが可能。
スタンダードサポートGitHubの使用時に発生した問題をWebフォームでサブミットすることでGitHub Supportが使用可能。 ※英語のみ対応

個人的にはチームで使うのだから、Github Actionの分数はもっと増やして欲しいなっと思いましたが、ブランチ保護やプロジェクトがGitHubで一元管理でき、サポートを使える点は良いなと思いました。

まとめ

いかがでしょうか?

私はCodeCommit廃止の報告を受け、各Gitツールの調査に結構な時間をかけて行いました。

他のGitツールも魅力的ですが、その中で選定したGitHubは、アカウント依存がなく、AWSリソースとのスムーズな連携が可能で、Dependabotによる自動的なパッケージ依存関係管理や脆弱性検出が提供されています。またコストも比較的リーズナブルで、今回の弊社の要件ではGitHubはより良い選択肢なのではないかと考えております。

これを読んでいただいた皆様の参考になれば幸いです。

Related posts