技術

CodeCommitを使う理由

現在、参画中の案件でCodeCommitをはじめて使ってみたので、その所感になります。

私はAWS大好き人間です。常日頃そのサービスの恩恵を受けており感謝していますし、AWSの技術力には尊敬しかありません。

ただ、CodeCommitに関してはいまいちと言わざるを得ません。おそらくAWS自体も、それほど注力しているプロダクトではないと思いますが。もし、自分がアーキテクチャー選定できるなら、CodeCommitはまったく採用する理由が見当たらないというのが結論です。

CodeCommitを導入した経緯

新規開発のプロジェクトで、GitリポジトリはGitHubでなくCodeCommitを採用するということになりました。

納品のしやすさと、セキュリティを重視したいという理由からです。

少し前に、ソースコードをGitHubのpublicリポジトリで流出させるという問題がありました。ただ、こういった問題は、開発者本人の問題です。問題の要因は、幾重におよぶ下請け構造によって、基本スキルすらない人材をプロジェクトに投入せざるを得ないという事情からくるものです。

なので、このようなセキュリティのインシデントは、GitHubからCodeCommitに変えたところで防げるものではありません。開発者が、CodeCommitからcloneしたコードを、GitHubの個人リポジトリに上げることは、やろうと思えばいくらでもできます。

つまりセキュリティという理由から、GitHubでなくCodeCommitを選ぶことは、まったく関連がない行為です。しかし、アーキテクトがいなくて、PMに意思決定が集中しやすいプロジェクトの初期フェーズでは、こういった決断が通ってしまいます。

開発者も経験がない技術スタックは使いたがるものなので、反対意見もそれほどあがりませんでした。(導入時は・・・)

CodeCommitのメリット

  • 安い
  • 納品がしやすい

価格

CodeCommitのメリットの一つは安いということです。

GitHubの場合は、組織アカウントやら外部のコラボレーターなどでライセンス料金が必要です。開発規模(リポジトリ使用人数)が大きくなればなるほど、料金がかかります。

一方、CodeCommitはAWSのIAMユーザだけで完結しますので、料金はほとんど変わりません。これが、CodeCommitを使用する一番のメリットです。

とはいえ、GitHubの価格体系はコロコロ変わり、どんどん安くなってきています。それに、システム予算の観点からですと、GitHubの使用料は、システムのリソースのコスト(クラウドの使用料など)と比較したら誤差みたいなものです。なので、今の所は価格メリットも言うほどではありません。

受託だと納品しやすいことがある

もう一つのメリットは、受託案件などで、リポジトリごと納品しなきゃ行けないときに、納品しやすいというものがあります。開発は、エンドクライアントのAWSアカウントか、もしくはAWSアカウントごと納品してしまうので、リポジトリもAWS上にあれば確かに楽です。

これは確かにその通りなのですが、GitHubを使えないというデメリットの方が大きいので、開発やリリース後の保守の不可を考えると、どうにかして説得するべきかと思います。

ただ、エンドクライアントがGitHub禁止という謎の企業ルールがある場合もあります。この場合はそもそもCodeCommitか、オンプレにGitリポジトリを立てるしかないので、諦めるしかありません。

AWSのCode系サービスとの相性はメリットではない

CodeCommitって、AWS製品だからCodeBuildやCodePipelineと相性が良いんじゃないのと思いがちですが、実はそうでもなかったりします。

GitHubと変わらないか、後述するクロスアカウントなどを考えるとGitHubのほうが良かったりもします。

CodeCommitのデメリット

CodeCommitを使用するデメリットは、いろいろあります。

機能不足

まず、GitHubと比較したら、圧倒的に機能が足りていません。そしてそれは、世の開発者にとってはGitHubがスタンダードということもあり、ほとんどの開発者が感じることです。

ざっと思いつくところで、以下の様な機能がありません。

  • IssueやProject、リリース管理がない
  • コミットへのリンクがない
  • pre-commitなどの機能がない(eventとLambdaを駆使して無理矢理やるしかない)
  • 通知機能が弱い
  • 権限周りの設定が、IAM設定になるので、管理しづらい
  • ログインしているAWSアカウントを切り替えると、アクセスできない
  • 巨大ファイルが表示されない
  • UIがいまいち

私個人としては、Issueがないのと、AWSログイン先を切り替えると使えないことに、かなりストレスを感じます。

クロスアカウントの設定が大変

デプロイ先が、CodeCommitと同一のAWSアカウントで完結するなら問題ないのですが、そんなことはほぼありません。たいていは、開発と本番でAWSアカウントを分けることがほとんどです。

CodeCommitを使うということは、CI/CDはCodeBuildやCodeDeployを使うことになるでしょう。その場合、CI/CDの権限の設定でクロスアカウントの対応が必要になります。開発アカウントにあるCodeCommtiを本番アカウントのCI/CDで呼び出すのに、IAMやKMSでクロスアカウントの設定が必要です。これはかなり面倒くさかったです。

また、Gitリポジトリを見ながら、本番アカウントでログインしてAWSの設定を見るといったこともできません。プライベートセッションや別ブラウザを使えばできなくはないですが、やはり面倒です。

Python環境の構築が必要

CodeCommitの場合、リモートリポジトリに対してGit操作するときは、Gitだけでなく、git-remote-codecommitが必要です。

これはPython環境で動作するので、別途Python環境が必要になります。ほとんど開発者のローカルには、Python環境はあると思うので問題になることはあまりありませんが、Pythonで作るシステムでもないのに、Python環境を構築する必要ということになったりもします。

AWS Credentialsの設定が大変

上記のgit-remote-codecommitは、当たり前ですがAWSアカウントにアクセスできないと動作しません。CredintialのデフォルトにCodeCommitがあるアカウントを設定するなら、それほど問題ないのですが、そうでない場合、少し特殊な設定が必要です。

また、GitでGUIツールを使いたいときも、CodeCommit用の設定をする必要が生じます。

結論 できるだけGitHubを使うべき

以上、CodeCommtitをプロジェクトに導入したときの感想でした。

個人的な感想としては、よっぽどのやむを得ないケースを除いてGitHubを使うべきだと思います。ブロッカーがいる(ある)なら、可能な限り取り除く努力をするべきです。