Goプロジェクトの依存パッケージは、 dep などのツールにより vendor ディレクトリに入るけど、「vendorをバージョン管理するべきかどうか」で定期的にチーム内で議論になる。

管理する場合、しない場合、それぞれの場合のメリット・デメリットをあげてみつつ考えてみる。

vendorをバージョン管理する場合

メリット

動かすまでが楽

何よりもこれ。cloneすればすぐbuild/runできる。動いている状態の完全なアプリケーション/パッケージとしてあがっているのだから当然。特定時点のスナップショット的なものになっているので、とにかく最初の一歩が早い。

デリット

リポ内のファイル数が爆増する

cloneするのが遅い。。大きめのリポジトリになると結構待たされる。 あと検索が弱くなる。vendor内も引っかかるのでGitHub Web上での検索は諦め気味。リポジトリを落としてからローカルで探すとこが多い。

vendorをバージョン管理しない場合

メリット

リポジトリが綺麗

この問題の先輩であるnpmはnode_modulesの中身を全部GitHubにいれたりしない。 GitHubが提供する .gitignore にもnode_modulesが書いてある。(Goにvendorはいない)
GitHubWeb上で検索しやすくもなる。

デメリット

動かすまでが大変

depがnpmほど洗練されていない、またGoの依存はGitHubのURLを指定できるようになっているのもあり、masterブランチを指定してる場合など悲惨だ。 このアプリケーション/パッケージが動いた時のmasterの状態などわかるはずもない。Gopkg.lockにrevisionとしてcommit shaが記録されているものの、force pushされたりするとあてにならないし、そもそも dep ensure 自体が結構な割合で失敗する。

結論

結局、一長一短で、メリット・デメリットが反対になっている。 個人的には 動かすまでが楽 これをものすごく重要だと感じており、Go自体のワンバイナリで気軽にどこでも実行できるというメリットとともに、 リポジトリをCloneしたらすぐrunできる というのは素晴らしいと思っている。

また、マイクロサービス化が進んでいくと、1つのアプリケーションを構築するのに複数のリポジトリを使うことになり、1つの修正や機能の実装のために複数リポジトリへの変更が必要になってくる。その時、各リポジトリのvendorを復元する手間が無視できないコストになる。本質的でないこの作業にコストがかかるのは色々ストレスだし、とにかくツライ。。

結果、今のPJでは。vendorもバージョン管理する(GitHubに全部突っ込む) にしていて、今のところ快適に運用できている。