Gitで安定マスターブランチを手に入れる
1 like2,669 views
小規模プロジェクトの場合、コードの守護神のような開発者がいればGitのマスターブランチの安定化は難しくありません。しかし大規模プロジェクトの場合、ブランチ戦略を考えないと、メインブランチの安定性はsubversion時代と大差ない結果になります。我々が目指したのは、「一秒」でも早く人の目に触れられる状態を作ることです。コードをpullするだけではなく、Kubernetesを始め様々なものを駆使して、「直ぐに確認」が出来る環境を目指しました。巨大プロジェクトで、安定マスターブランチを目指して試行錯誤した経験をお話します。
Gitで安定マスターブランチを手に入れる
- 2. 自己紹介 その１ 井上 誠一郎（いのうえ せいいちろう） HUE & ATE Div. Partner 主な著書 - Perfect Java - Perfect Java EE - Perfect JavaScript - ITは本当に世界をより良くするのか？IT屋全力反省会 (翔泳社)
- 3. 自己紹介 その２ 三宅 泰裕 （みやけ やすひろ） Platform Dept. Manager 主なお仕事 - 日々、開発者のために汗水垂らして地盤整備
- 4. 規模感 開発人員 数千人（日本・中国・シンガポール・インド） 開発規模 - Gitレポジトリ数: 数千 - トピックブランチ: 星の数ほど まぁ、超大規模開発ですよ...
- 8. 現実問題として 多種多様な検査ロジック 機能 * 機能で生み出される機能 イントラネットからSaaS への転換 世の中の変革、スマートデバイスの対応 etc... 当然、我々もそこに追従することを余儀なくされました
- 11. モノリス !!
- 12. この時の記憶... (遠い目) 開発規模 ：数百人 ビルド時間 ：30時間+ ランタイム ： r3.16xLarge * いっぱい ＋ =
- 14. それや！！
- 15. そうだ、マイクロサービスになろう!! 下記の作戦でとりあえずやってみる ・ 共通部分（ライブラリ）をとにかく外出しする = jarにする ・ 細切れになった共通部分のビルドをバラバラにして、バージョン振る ・ 残りの巨大モノリスを、「どうしようもないもの」と「分かれそうなもの」 ・ 「分かれそうなもの」をとりあえず細かく砕いてみる ◆
- 19. 全然、おいしくない... 美味しい ● 各warは異なるjarのバージョンをもてる ● ビルドの単位もバラバラ 美味しくない ● 後方互換性を保ててない ● 業務ドメイン単位でのバージョンアップ ● そもそも、業務ドメインの境目はとても曖昧 結果として、ビルドは速くなる。単体でデプロイも出来る。でも、動かないし、結局高いし...
- 20. どうしよう...
- 21. よく考えてみることにした バージョン違いのライブラリが存在する +1 ビルドの単位もバラバラ +1 後方互換性... -10 業務ドメイン単位でのバージョンアップ -100 そもそも、業務ドメインの境目はとても曖昧 -1000 これってもしかして... みんな、テストできてな くない？
- 22. それや！！
- 23. あれ？なんか足りなくない？？ お金も安くないので、「テスト出来ない」問題を解決に走ることにする なんで出来ないんだろう... - 「メモリのことを気にするなんて...」ニュータイプすぎる議論 - 「クラウドなんて、ブラックボックス」なナウでヤングな感覚 - 「必要ならたてるまで、ですよ」開発元気玉をしようとする◯空 - 「いいか、更新は慎重にするんだぞ、赤い線を切れ、切るんだ !!」
- 24. 開発環境がナイ !!
- 30. じゃあ、使っちゃおう 救世主OpenStack + k8s ステートフル担当 = DB ステートレス担当 = AP
- 31. 結果、こんな感じになる
- 40. まとめ 安定化の肝は「開発環境」 - 心理的障壁を下げる効果も 再利用・破棄可能な形にして、早い段階からデプロイする - コストメリット - 生産性の向上 規模的な制約もあってCloudを選ばなかっただけで、Cloudでも勿論構わない
- 41. ご静聴ありがとうございました