小規模プロジェクトの場合、コードの守護神のような開発者がいればGitのマスターブランチの安定化は難しくありません。しかし大規模プロジェクトの場合、ブランチ戦略を考えないと、メインブランチの安定性はsubversion時代と大差ない結果になります。我々が目指したのは、「一秒」でも早く人の目に触れられる状態を作ることです。コードをpullするだけではなく、Kubernetesを始め様々なものを駆使して、「直ぐに確認」が出来る環境を目指しました。巨大プロジェクトで、安定マスターブランチを目指して試行錯誤した経験をお話します。

1. 16-C-3
Gitで安定マスターブランチを手に入れる
株式会社ワークスアプリケーションズ
井上 誠一郎、三宅 泰裕
#devsumiC

2. 自己紹介 その１
井上 誠一郎（いのうえ せいいちろう）
HUE & ATE Div. Partner
主な著書
- Perfect Java
- Perfect Java EE
- Perfect JavaScript
- ITは本当に世界をより良くするのか？IT屋全力反省会 (翔泳社)

3. 自己紹介 その２
三宅 泰裕 （みやけ やすひろ）
Platform Dept. Manager
主なお仕事
- 日々、開発者のために汗水垂らして地盤整備

4. 規模感
開発人員
数千人（日本・中国・シンガポール・インド）
開発規模
- Gitレポジトリ数: 数千
- トピックブランチ: 星の数ほど
まぁ、超大規模開発ですよ...

5. 今日、お話したいこと
我々の環境安定化の為の闘争の歴史。
涙なしでは語れないあの日々のことを...
全ての問題を解決できたわけではありませんが、
超大規模開発の中で何を考えどのように変革をしていったのか。
その中で得られた知見を皆さんにお話します。

6. 簡単にいうと、こういうことです

7. さて…
インフラのお守りをしていると、トラブルに見舞われない日はないですよね？
フルマネージドで
洗練されたパイプラインが存在して
コード書いたら、テストもされて、すっとプロダクションまで伝搬される。
こんな世界は神話の世界かなぁと思ってました。
実際、今も思っています...。

8. 現実問題として
多種多様な検査ロジック
機能 * 機能で生み出される機能
イントラネットからSaaS への転換
世の中の変革、スマートデバイスの対応 etc...
当然、我々もそこに追従することを余儀なくされました

9. 誤解と混乱...、いやぁ阿鼻叫喚っす

10. 山に登る理由？そこに山があるからだよね？
ガムシャラに走ります。分からなくても走ります。
ふと、後ろを眺めると....

11. モノリス !!

12. この時の記憶... (遠い目)
開発規模 ：数百人
ビルド時間 ：30時間+
ランタイム ： r3.16xLarge * いっぱい
＋ =

13. 教訓めいた会話
Aさん「ビルドの待ち時間長過ぎて、脳内デバッカーが進化しました」
Bさん「僕たち、Jenkinsの奴隷じゃないんですけど？」
Cさん「ピリオドの向こうが見えてきました...」
Dさん「細かくすれば、良いんじゃね？」

14. それや！！

15. そうだ、マイクロサービスになろう!!
下記の作戦でとりあえずやってみる
・ 共通部分（ライブラリ）をとにかく外出しする = jarにする
・ 細切れになった共通部分のビルドをバラバラにして、バージョン振る
・ 残りの巨大モノリスを、「どうしようもないもの」と「分かれそうなもの」
・ 「分かれそうなもの」をとりあえず細かく砕いてみる
◆

16. こんなイメージ：業務ドメイン + ライブラリ
モノ
ライブラリ
カネ
ヒト
ライブラリ
ライブラリ
ライブラリ
ヒト
カネ
カネ

17. 土台はKubernetes、 Prometheusも参戦
モノ
ライブラリ
カネヒト
ライブラリ
ライブラリ
ライブラリ
ヒト
カネ
カネ

18. デプロイしやすくしてみると、重複に気づく
モノ
ライブラリ
カネ
ヒト
ライブラリ
ライブラリ
ライブラリ
ヒト
カネ
カネ
◆

19. 全然、おいしくない...
美味しい
● 各warは異なるjarのバージョンをもてる
● ビルドの単位もバラバラ
美味しくない
● 後方互換性を保ててない
● 業務ドメイン単位でのバージョンアップ
● そもそも、業務ドメインの境目はとても曖昧
結果として、ビルドは速くなる。単体でデプロイも出来る。でも、動かないし、結局高いし...

20. どうしよう...

21. よく考えてみることにした
バージョン違いのライブラリが存在する +1
ビルドの単位もバラバラ +1
後方互換性... -10
業務ドメイン単位でのバージョンアップ -100
そもそも、業務ドメインの境目はとても曖昧 -1000 これってもしかして...
みんな、テストできてな
くない？

22. それや！！

23. あれ？なんか足りなくない？？
お金も安くないので、「テスト出来ない」問題を解決に走ることにする
なんで出来ないんだろう...
- 「メモリのことを気にするなんて...」ニュータイプすぎる議論
- 「クラウドなんて、ブラックボックス」なナウでヤングな感覚
- 「必要ならたてるまで、ですよ」開発元気玉をしようとする◯空
- 「いいか、更新は慎重にするんだぞ、赤い線を切れ、切るんだ !!」

24. 開発環境がナイ !!

25. ありがちな構成
とりあえず、データベースがあればいいだろう構成
DB

26. Micro Service Architecureなら当然、APも必要
DBAP

27. 共有すればするだけ足を引っ張る
DBAP
更新の競合、適用による破壊

28. 幸せな世界は、こんな感じ
環境も「疎」にする
DBAP DBAP

29. これ、どこに作るの？
クラウドに作りまくると、それなりにお金がかかる
弊社の場合は、埋蔵サーバ（PC）が転がっていた

30. じゃあ、使っちゃおう
救世主OpenStack + k8s
ステートフル担当 = DB ステートレス担当 = AP

31. 結果、こんな感じになる

32. この環境の副次的な効果
いくら壊しても文句言われない（世界中からヘイトを集めるとかない）
慎重派なあなたも大胆なことが出来るようになる
依存関係（重複部分の解消）
ビルドのスクリプトの改善
なんなら、俺も今日からCIやるぜという気概と気合
結果的にどんどん欲が出てくる＝これは凄くいいこと

34. 更なる挑戦が出来るようになる
もっと早期段階でテストしたいYo !!
ベースはk8s, これならトピックブランチからそのまま環境作ってみる？
ここからdeployする

35. これが出来るのは開発環境ならでは
QEがテストを続けているような環境では心理的障壁もあり厳しい
しかし、人手で見るしかない部分
・ UI/UXの確認
・ 機能の概要を確認する
を先に行えるなら、手戻り少なく開発も出来る
結果的には、マスターブランチが不安定になりにくい

36. 壊してもいつでも戻せる「安心感」は大事
QEがテストしている環境を適用によって破壊すると、鬼の様にヘイトが飛んでくる
それが例えSlack越しにBotが呟くことだとしても
人は弱いので傷付くものです...
自身のチームで「やっちまったー！」は、きっと許されますよね？
この安心感の中でのびのびやるのが、モノリシックから脱却しようとしている
サービスには大事なことなのかもしれません…。

37. 次なる挑戦（予告）
この手法はステートレスな層にのみ適用できます
が、永続層はどうでしょうか？
まだまだ、問題がありそうです…。
次に攻めるのは、当然データなので…。
ユニットテストをリッチにしようと企んでいます。

38. 実値でテストするテストを当たり前に
昔懐かしのDBUnitにはトランザクションを頑張ってコントロールする機能が
ありました。DDLなどRollBackが効かないものには無力さを覚えるものです
OpenStackの機能を有効利用することで美味いこと料理できそうです

39. テスト前につけて、終わったら破棄
volume
テスト
volume
完全な確証はまだないですが、仕組みの検証段階での効果は抜群です

40. まとめ
安定化の肝は「開発環境」
- 心理的障壁を下げる効果も
再利用・破棄可能な形にして、早い段階からデプロイする
- コストメリット
- 生産性の向上
規模的な制約もあってCloudを選ばなかっただけで、Cloudでも勿論構わない

41. ご静聴ありがとうございました