trunkのビルドが通らないのは是か非か

社内でsubversion（アクセスするのは社内チームメンバーのみ）を用いて、
アプリケーションを開発しているのですが、
先輩の中に、ビルドが通らない状態でtrunkにコミットする方がいます。

もちろん、コミット漏れなどでビルドが通らなくなることはあるかと思いますし、
その際はJenkinsなどで通知もきますし、急いでいる場合は一言伝えるだけで解決するので、気にはしていません。

ただし、その先輩は新規モジュール作成や、リファクタリング時のsaveの意味で
ビルドが通っていないことを認識した上でtrunkにコミットをします。

当然、他のメンバーのビルドに影響が出るため、私としては作業がしにくいと感じており、
先輩にその旨を伝えたところ、

「開発中にtrunkのビルドが通らなくなるのは普通。オープンソースプロジェクトでもtrunkのビルドが通らないのは当たり前」

と言われました。

つまり、先輩の認識では、trunkのビルドが通らないことは悪ではないということなのです。

確かに、オープンソースプロジェクトでtrunkのビルドが通らないのはよく見かけますが、
それは不特定のメンバーがコミット可能である以上、仕方のない面もあるのかなと思っています。
（オープンソースプロジェクトに参加したことはないので、trunkに直接コミットできるのかは確認していません。認識が間違っていたらすみません）

少なくとも、オープンソースプロジェクトのtrunkと
限定されたメンバーでの社内プロジェクトのtrunkは意味合いが異なり、
社内プロジェクトのtrunkはビルドが通った状態でコミットするべきではないかと考えています。

ビルドが通らない状態でセーブしたいのであれば、branchを切るか、svkやgitでローカルリポジトリにセーブするべきだと思っています。

私の認識は間違っているでしょうか？
皆様のtrunkの運用ポリシーを教えていただければ思います。

No.1 回答者： Wr5 回答日時： 2011/11/20 23:41

個人的には…不具合があるとしても最低限ビルドの通るモノを…と思いますね。

まして、他のメンバーに影響するのであれば。

まぁ、私の使っているリポジトリは私しか使用しないため、たまにビルド確認できないモノをコミットすることはありますが。
# それでも、コミットログに「ビルド未確認」とかコメント入れてますが。
# 後から「ビルド確認」したモノがコミットされることに…。

>新規モジュール作成や、リファクタリング時のsaveの意味で
であれば、私なら最初からその為のブランチ切ります。
後でマージすれば済む話ですし。
# マージで衝突しない…とも限りませんけどね…。

社内でのプロジェクトなのですから、上長などに掛け合ってルール化するべき…かと思います。
その先輩は反対するでしょうが、事実他のメンバーに迷惑かけているのならば、なんらかの調整は必要でしょう。
その先輩が行ったコミットのせいで全体の進捗が遅れても責任とってくれる。というのなら、まぁ取って貰えばいいでしょうし。
# なんだかんだ言って逃げるでしょうけどねぇ。　過去のリビジョン取ってくればいいじゃないかとか…。


ちなみに、オープンソースのプロジェクトには参加したことの無い者の意見ですけどね。

No.2 回答者： wormhole 回答日時： 2011/11/21 00:21

私のかかわったプロジェクトだと

最低限コンパイルできる事を確認した上でコミットするように
お願いしています(私が運用ポリシーなど決める側でなくても)。

でないと他の人の開発に影響出過ぎますから。
その先輩は、それがどれだけ他の人を困らせる行為なのか
わかってないんじゃないんですかね。
プロジェクトメンバーの集まるミーティングでの
議題とかにした方がよいのではないでしょうか。

＞「開発中にtrunkのビルドが通らなくなるのは普通。オープンソースプロジェクトでもtrunkのビルドが通らないのは当たり前」

正直、その行為を正当化する理由にはまったくなってないと思いますが・・・
オープンソースプロジェクトが全てそうというわけでもないでしょうし。
その本人だけの常識って気が・・・

No.3 ベストアンサー 回答者： hanabutako 回答日時： 2011/11/21 00:39

間違ってないと思いますよ。

trunkは全員が共通して使う最新のコードであることを想定し、まず、build可能なもの、そしてtestが通るものを置いておくべきです。buildすらできないものは無条件にrevertされても文句言えないと思います。そして、testがないもの、testが通らないものは理由がない限りは入れてはいけないと思います。

ある程度大きなOSSの場合、普通の開発者においそれとコミット権をくれないですよね。そして、普通の開発者が本体にプログラムを入れたい場合、デザインレビューからソースコードレビューまでの関門を通り抜けて、コミッターによってテストされた上でコミットされると思うんですが。
よく壊れているというのは何のプロジェクトでしょうか？

まずは上司も含めたミーティングでtrunkのポリシーについて話しあってはいかがでしょうか。
リファクタリングの最中でも最低限buildが通る形で進化させていくことは可能だと思います。もちろん、その場合は今後どういう形にするというドキュメントがあったほうが好ましいです。
また、新規モジュールを作る場合は一緒にテストも作っておくことをお勧めします。テストがないとそれが期待する動作をするのか否か判定できず、バグが見つかった時にどのモジュールのせいなのか即座にわからないですからね。それに、テストコードはそのモジュールの期待される使い方、期待されない使い方を示しているのでそこを他人が理解するのにも役立ちます。

この回答へのお礼

具体的な名前を出すのは控えますが、比較的小規模なOSSです。
先輩にも確認してみましたが、「大きなプロジェクトはしっかりしているからtrunkのビルドが通らないケースは少ない」といってました。（痛いところを突かれたようで苦笑いしてました）

結局チームとして、trunkのビルドは通る状態でコミットする方針にしていこうと思います。

大規模OSSのコミットの流れを教えていただいたので、ベストアンサーとさせていただきます。

お礼日時：2011/12/01 21:41

No.4 回答者： okbakasine 回答日時： 2011/11/22 02:27

会社としての開発時の規約は?

普通は、バージョン管理サーバにコミットするときは最低限、ビルドが通る物って決めているはずでけど
その規約は存在する?
まぁその手の規約には絶対にクラス名や関数の命名規約や変数名の命名規約はコーディングの規約(インデントをタグにするかスペースにするかなど)が絶対にあるはずですけど
で、この手の開発時の規約を守らないと給与査定にも響くはずだし下手したら解雇。

>開発中にtrunkのビルドが通らなくなるのは普通。
誰がそのコードをいじっても良い状態のオープンソースならそれはアリだけど
仕事した場合そのコードを担当以外がいじるのは問題あるから
勝手に修正してビルドが通る状態にするだけでも大問題。だからこそビルドが通るソースをコミットするのが常識。


とりあえずブランチで対処する気すら無いならバージョン管理システムを切り替えるしか方法は無いのかな?
gitあたりにでも(これなら開発中の部分は中央サーバにあげずに個人の環境だけでコミット作業できるわけですし)
そういえば個人環境ではgitを使って中央サーバではsubversionを利用する方法ってあったね。
http://sourceforge.jp/magazine/09/03/26/0834222
こんな感じで