LinkedIn の開発で使用されている開発手法「continuous deployment」 21
ストーリー by reo
量と時間の差? 部門より
量と時間の差? 部門より
insiderman 曰く、
米大手 SNS「LinkedIn」では、continuous deployment と呼ばれる開発手法が採用されているらしい。それぞれの開発者が一定量のコードを書くと、自動的にテストが実行され、テストをパスすると trunk にマージされる仕組みになっているそうだ (WIRED.jp の記事、本家 Wired.com 記事より) 。
継続的インテグレーションと何が違うんだと思って原文をチェックしたのだが、明解な答えは見つからなかった。ただ、LinkedIn は以前は複数のブランチに分けて開発を行い、数日もしくは数週間単位で trunk にマージしていくという方式だったそうで、マージ時に発生する問題を避けるために同時に開発する機能に制限を加えざるを得なくなり、開発が停滞していたそうだ。continuous deployment の採用によりこのような問題が解決され、開発速度が一気に向上したという。
つまり早い者勝ち？ (スコア:1)
コミットが遅れると、自分と重複するコードを書いていた奴とコンフリクトするから
書き直しになる可能性がある、と。
遅れを取らないようにコードを早く書き上げるようになるので
開発速度が上がると。
上手く他人と調和するコード書いていけるうちはいいかもしれないが
衝突が嫌なやつが他人と被らないようにコードを書いていくことになって、
同じ機能がいろんな部分に分散する危険性もあるんじゃないかな、と。
Re:つまり早い者勝ち？ (スコア:3)
自チームの開発に必須のコードがあって、そのコードの単体テストが甘い場合は、
単体テストで明確になってない振る舞いが変更される可能性が高く、
コンフリクトのリスクとコストが発生しやすい。
自動マージだと、なおさら不安になるし、泥をかぶるのは自チームになる。
（今までなら、チーム間のコンフリクトを解消するためのコストは普通は両チームが払う）
他チームの開発によってコードの振る舞いを変えられる可能性を減らすため、
仕様として甘かった箇所を単体テストに追加する作業を、コーディングより先に行って
「ここは変えるなよ」という牽制を、単体テストで宣言するという面白いスタイルになりそう。
コンフリクトの回避＆単体テストの補強により仕様が明確化がされるというオマケ付き。
早いもの勝ちは別として... (スコア:1)
修正が重複しないように設計、開発管理するとかシステムが修正を認識しやすいコード規約とか。
もうちょっと贅沢言えば、ソースそのものではなく一旦論理的単位でバラしてcommitするような仕組みとかね。
indent通してからcommitするのの拡張みたいな。
Re: (スコア:0)
結局
＞マージ時に発生する問題を避けるために同時に開発する機能に制限を加えざるを得なくなり
を大声にするか小声にするだけかのような感じですかね
Re: (スコア:0)
コンフリクトした後の修正がいやだから、別のフォルダ（管理外）で作業して、
最新のソース取得してそれに上書き後、コミットしてたやつがいて大変だった
※彼はコンフリクトしない方法としてあみだしと自慢してた
Re:つまり早い者勝ち？ (スコア:1)
コミット時にテストが走る方式だとコンフリクトするはずだった機能の
テストがコケるからバレるよ。
そういう奴には今回の仕組みは有効に働くかな。
ただコンフリクトが起きなきゃいいんじゃなくて、コンフリクトは
まずは正しく回避して、それができずに発生したら正しく解決しましょう、と。
Re: (スコア:0)
それはgitのブランチ分け+rebaseと違うの?
「大変だった」というには、いろいろ問題があったのだろうし、rebaseもコンフリクトを完全に排除する訳じゃないけど。
...まさか「上書き」の際に、元ソースの本来ぶつかる部分を戻しちゃってたとか?
Re:つまり早い者勝ち？ (スコア:1)
君は元コメを理解するには恵まれすぎているようだな。
てかrebaseはマージしたものの管理方法が違うだけで普通にマージだよ。
Re: (スコア:0)
そのまさかでしょう。
Re: (スコア:0)
それは即時ビルドブレークを発生させ、最終コミット者として彼が周りからの袋叩きに合うと思うのだが違うのか？
Re: (スコア:0)
実はそれに必要なのが、参加全員の立場の均等化。
均等化が成されていれば、自然と事前の情報の共有の必要性は認識される。
最初は難しくとも、問題が出る度に考えれば、そのうちは何とかなる。
均等化が成されて居なければ、そりゃ無理言う奴の弊害を周りが被るって良くある光景になるだけ。
CIのその先 (スコア:1)
> 継続的インテグレーションと何が違うんだと思って
継続的インテグレーションは単体テストとビルドの自動化だけど、
継続的デプロイはそれに加えて、自動化された配置プロセスを含んでいます。
（単体テストだけではなくてスモークテストも自動化するでしょう）
継続的デリバリーと違うのは、必ずしも「リリース」ではない、という点ぐらい。
Re: (スコア:0)
継続的インテグレーションにはそれも含まれると思ってた。
まあ、どうでも良い言葉の定義だけど。
Re: (スコア:0)
継続的デプロイは配置先の環境によって色々変わってくるからそこは分けて考えてあげてください
自動マージとかいやすぎる (スコア:1)
コード量単位でのマージ(コミット)はコード差分の粒度に問題がある。
タスク管理ツール側の案件とのリンクが不明瞭になりトラックが困難になるしRevertもやりづらくなりますよ。
#でもね、どちらの環境にもいましたが確かにタレコミ方式のほうが開発速度が速いんですよ・・
Re: (スコア:0)
経験者ということでお聞きしたいのですが、日付単位での自動化とコード量単位での自動化だと、どうして後者が早くなるんでしょうか?
日付でも、毎日ビルドすれば差は出ないように思いますが。
僕が勘違いしている可能性は大なので、頓珍漢な質問かもしれませんけど。
Re: (スコア:0)
機能・案件単位でのコミットとコード量単位でのコミットの比較のつもりでしたが..
コミットの際に案件とのリンクを作ったり確認作業の手間がかかるなどがありますが、
開発者の心理的な面も大きいのでしょうね。
不具合No.43532への対応とかじゃなくって俺はリファクタリングしたいんだーみたいな・・
前の会社で (スコア:0)
ヘッドハンターから電話がかかってくるたびに
Linked-inでメッセージ送ってねって言って電話切って、
そのまま無視するってやつがいた。
Linked-inが悪いわけじゃないんだけど、
人がゴミ箱にしてるのを見てたので、なんかイメージ悪い。
Re: (スコア:0)
イメージ悪くないんだけど
日本では空気なイメージ
Re: (スコア:0)
単純に自分にはヘッドハンティングのオファーが来ないので嫉妬してるだけでしょうなあ。
Re: (スコア:0)
楽天専用の捨てアドに。