trunkを常にリリース可能に保つために分散リポジトリは有用なのか？

t_yano @t_yano

最近リリースをうけもっているため，trunkを「常に」リリース可能なものに保つようにすると開発に不効率さを招くという危機感がある。これを解決するために第一に考える手法は，分散リポジトリだと思う。 *P3

t_yano @t_yano

各チームで「リリース対象にならないレベルの」コミットを行うリポジトリを持ち，リリースに回していいものだけをtrunkにあたるサーバ上のリポジトリにpushする，ということをやるのが一番いいんだと思う。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano それ別に分散リポジトリと関係ないのでは。 *Tw*

t_yano @t_yano

亀mercurialはなかなか良いという情報があるのだが，亀Gitはどうなんだろう。私はコマンドラインでもいいんだけど，チーム全員そうしろというのも辛いかもしれんので，亀シリーズ使えれば楽。個人的にはmercurialのほうが簡単だと思うが，Git好きのほうが多い。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano ヒエラルキー構造を持って開発する、というところに分散リポジトリならではの柔軟さが生かせるということじゃないかと。 *Tw*

t_yano @t_yano

@cactusman チームごとにコミット可能なブランチをもって，リリース可能ブランチも用意して適時そっちにマージしてくれという手もあるが，実感としてそのマージはけっこうしんどい。というかsvnのマージはなんかしんどい。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano Subversionのマージがしんどいのはありますが、分散リポジトリでもTrunkにコミットしてビルドが破壊されるのは同じだと思います。 *Tw*

t_yano @t_yano

@cactusman 分散リポジトリが作られた本来の用途とかは今の件ではあまり重要ではなく（まあただの道具だし），今の問題を解決するために一番使いやすそうな道具を探したら，どうも分散リポジトリっぽいな，という話。 *P3

t_yano @t_yano

@cactusman いやそもそも「コミットする先がtrunk」という状態をやめたい，という話でして。テスト完了してなくてもコミットしたいので，そういうリポジトリとテスト済みリポジトリを分けたい。後者がsvnでいうtrunkの位置づけで，Git/Mercurial系なら， *P3

t_yano @t_yano

@cactusman 「テストが済んだものは全部trunkにpushしておいて」で済みそう。そりゃまあマージはもちろん発生しますが。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano 言わんとしているところはわかりますが、それぞれ独立してテストが通ったコードがマージしたらテストがこけるというのは往々にしてあるわけで。 *Tw*

t_yano @t_yano

@cactusman そりゃーHudsonが落ちたら巻き戻せって話になるでしょうねえ。。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano ローカルに作業用としてコミットしたい、とかほかの人の変更を気軽に取り込みやすい、というところで評価しているのはわかりますが、trunkを「常に」リリース可能なものに保つには、たりないはずです。 *Tw*

t_yano @t_yano

あとまあ，いまのプロジェクトだとサブシステム単位で別々のアプリに切り分けられてて結合部分は少なめってのもあるかもね。結合で問題が起きたら「リリース中止」になるが，格サブシステムのtrunkが「リリース不能状態」と「リリース可能状態」を往復し続けるよりはいいかな。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano どっちかというと、ミスったのを検知するのが大事かと。その前に戻せばリリース可能な状態になるわけですし。 *Tw*

t_yano @t_yano

@cactusman んーどこを指摘されているのかがよくわからん。「それじゃ100%完全に常にリリース可能にはならない」という点には同意しているが，一方「100%完璧」は目指してない，といったら回答になる？ いまよりマシにしたい。 *P3

t_yano @t_yano

@cactusman trunkは常にCIでチェックしてるので落ちたらメールですぐ分かるようにしてる。いまの問題は「テストが落ちない」レベルではコミットできるけども「いま作ってるテストは落ちないけど，まだ全テストは書き終わってない」って状態で *P3

t_yano @t_yano

@cactusman 状態でのコミットがしづらい（テスト未完のものがコミットされることになるので），しかし開発上コミットはばしばし行いたい，という部分にある。じゃあばしばしコミットできる環境を別に用意しよう，という解はおかしい？ *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano 分散SCMを使うことで楽になる、というのはわかっていますよ。ただ、それも運用次第かと。 *Tw*

t_yano @t_yano

@cactusman んーわかるんだけど，まあ，同意ですよ＞運用次第　　私の中では「運用次第」なのは自明だったので...　別に分散リポジトリにしたら自動的に望んだ環境が手に入るとは思ってないので。望んだ環境を手に入れるのに使えそうな道具だね，という話なんで。 *P3

t_yano @t_yano

「道具はどう使うか」という点は同意してる，というか，道具を採用したら自動的によくなる，なんてのは期待してないし信じてもいない。 *P3

t_yano @t_yano

それって「struts使えばうまくいくはず」「rails使えばうまくいくはず」ってのと同列だと思ってるので，別に分散リポジトリを使うことが目的ではない。というか，使ったところで役立つシーンがないのならいらないし。。。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano trunkを「常に」リリース可能なものに保つようにすると開発に不効率さを招く、というのは運用の仕方の話で、そもそもリポジトリの種類とは関係ないはず、ということが言いたいのですよ。 *Tw*

t_yano @t_yano

@cactusman なるほど，svnでうまい方法があるなら教えて欲しいです。私はうまい方法が見つからなかったのでそっちにながれてるだけで，あればそっちに流れますよ。問題が解決するならなんでもいいです。 *P3

さぼてん（さぼ福）🌵 @cactusman

@t_yano で、矢野さんが問題にしていることは、ローカルコミットを行いたいということと、マージをできるだけ楽したい、ということじゃないかと。それだと分散SCMですよね、という話になるはず。 *Tw*