"最後のページ"にお楽しみがあります

1. Git実践入門
JJUGナイトセミナー Git入門
2016-01-25（月）19:00 - 21:00

2. • しょぼちむ
• @syobochim
こんばんわ！

3. 受託開発
お客様は金融系
基盤チームのメンバーとして案件に参入

4. 結論から言うと
少人数チームでGit導入するのはいいけど
大規模でやるためには
本当にちゃんと運用フローを考えて
体制を整えるか
ある程度妥協しないと
大惨事になるということ

5. ※あくまでイメージです

6. 今日は私や、私の周りの人が
案件にGitを導入・運用した時の
開発プロセスについて
お話ししていきます

7. まずソースコードを管理するための
基本的な開発スタイルについて

8. 開発スタイル

9. 構成管理サーバ : GitBucket

10. CI : Jenkins

11. mavenリポジトリ : artifactory

12. ちなみに全部無料！

13. (Redmine以外は)JVMで動く！

14. 今日はここの話をします

15. ちなみに全体のざっくりした説明は
↓に書いてます
http://syobochim.hatenablog.com/
entry/2015/09/03/214050

16. GitBucket
構成管理用の
リポジトリ管理ツール

17. GitBucketのいいところ
• インストールが簡単
• 無料！
• GitHubに似ているから
普段GitHubを使ってい
る人には親しみやすい

18. GitBucketのインストールDEMO

19. warを直接起動できる！かんたん！
ちなみに環境構築についての
ブログ書きました
http://syobochim.hatenablog.com/entry/
2015/05/31/232650

20. https://github.com/gitbucket/gitbucket/wiki/Backup
極たまにデータが飛ぶことがある
バックアップを取得しておくことが大事
困ったこと

21. GitBucketは無償と思えないほど使いやすい！
無償＋インストールが簡単なので「とりあえず
やってみよう！」の
ハードルが低い
ただ、トラブル対応などで
導入・運用のコストはかかってしまうので
可能なら最初から有償ツールを
検討した方がいいかも

22. プロジェクトの構成とブランチモデルについて

23. プロジェクト構成やブランチモデルは
プロジェクトの体制や要員のスキルに
合わせて一番検討する必要があります

24. • ケース１
‣ 小規模で構成管理の大切さを知っている人
が各拠点に一人はいる体制
• ケース２
‣ 小〜中規模でGitを知らない＋構成管理につ
いて知らない人たちがほとんどを占める体
制
• ケース３
‣ 中〜大規模でGitを知らない＋構成管理につ
いて知らない人たちがほとんどを占める体
制

25. ケース１
• アプリチーム２つ×基盤チーム１つ
• プロジェクトの体制は小規模（１チーム10人未満）
• アプリチームも基盤チームも主体的に行動している
• 基盤チームはアプリ開発への影響を理解している
• アプリチームは基盤部品の重要度を理解している
• 必要な基盤部品の提供時期がアプリチームの計画とマッチして
いる
• 構成管理についてある程度のスキルや知識をもっている人が各
チームに一人はいる

26. プロジェクト構成
• チームや拠点ごとにリポジトリが分かれるようにする
• 画面・バッチ・基盤ごとにチームや拠点が分かれている
• ベースリポジトリとサイトリポジトリに分けている

27. ベースリポジトリ
• ライブラリアンのみmerge / pushする権限がある
• リリースしてもいいソースのみを格納する

28. サイトリポジトリ
• 拠点ごとにリポジトリを分けている
• 各開発者が直接push / pullする

29. サイトリポジトリ
開発拠点は違うが同じフレームワークを使う場合は
共通用リポジトリから更にリポジトリをforkさせていく
fork

30. ブランチ
• 開発者はfeatureブランチを作って開発をする
• pull request形式でレビューをする
• サイトリポジトリのmasterブランチへのマージは責任者がやる
• ベースリポジトリへのマージはライブラリアンがやる

31. ブランチ
• 開発者はfeatureブランチを作って開発をする
• pull request形式でレビューをする
• サイトリポジトリのmasterブランチへのマージは責任者がやる
• ベースリポジトリへのマージはライブラリアンがやる

32. ブランチ
• 開発者はfeatureブランチを作って開発をする
• pull request形式でレビューをする
• サイトリポジトリのmasterブランチへのマージは責任者がやる
• ベースリポジトリへのマージはライブラリアンがやる

33. ブランチ
• 開発者はfeatureブランチを作って開発をする
• pull request形式でレビューをする
• サイトリポジトリのmasterブランチへのマージは責任者がやる
• ベースリポジトリへのマージはライブラリアンがやる

34. ブランチ
• 開発者はfeatureブランチを作って開発をする
• pull request形式でレビューをする
• サイトリポジトリのmasterブランチへのマージは責任者がやる
• ベースリポジトリへのマージはライブラリアンがやる

35. いいところ
リポジトリごとにpush権限を変更できるので
「あっ！間違えてpushしちゃいました！」
というミスをシステム的に防ぐことが出来て安全
自分たちがどのチームにいて
何を開発しているのかが明確になる
フレームワーク用にリポジトリを分けているので
自分たちの好きなタイミングでフレームワークの変更を
取り込むことができる
拠点間でのビルドの失敗が他の拠点に影響を与えない
他の会社からのソースコード受け入れ時に
対象ソースが何かがわかりやすい

36. いまいちなところ
運用コストが高い
フレームワークの変更の取り込みタイミングを
各拠点に任せるので
「後でいいや」って思い続けられると死ぬ

37. ケース３つのまとめ
ケース１
運用コスト ×
フレームワーク変更
の取り込む速さ △
フレームワーク変更
の取り込みタイミン
グを決められる
◯
リリース成果物への
権限設定 ◯
レビューしたものの
み成果物に出来る ◯
所感 重厚

38. ケース２
• アプリチーム複数×基盤チーム１つ
• プロジェクトの体制は小〜中規模
• 構成管理についてあまり知識がない人ばかり

39. プロジェクト構成
• 画面・バッチ・基盤ごとにモジュールが分かれている
• ブランチ単位で開発拠点やリリース用ソースを分けて
いる

40. プロジェクト構成
• リリース用のブランチを作って、そこからリリース成果物を
作成する
• 開発者はリポジトリに対して直接pull / pushをする

41. ブランチ
• 開発者はfeatureブランチを作って開発をする
• 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける
• pull request形式でレビューをする
• masterブランチへのマージはライブラリアンがやる

42. ブランチ
• 開発者はfeatureブランチを作って開発をする
• 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける
• pull request形式でレビューをする
• masterブランチへのマージはライブラリアンがやる

43. ブランチ
• 開発者はfeatureブランチを作って開発をする
• 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける
• pull request形式でレビューをする
• masterブランチへのマージはライブラリアンがやる

44. ブランチ
• 開発者はfeatureブランチを作って開発をする
• 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける
• pull request形式でレビューをする
• masterブランチへのマージはライブラリアンがやる

45. いいところ
自分たちがどのチームにいて
何を開発しているのかが明確になる
フレームワークの変更をdevelopにmergeするので
素早く変更を反映・取り込むことが出来る
拠点間でのビルドの失敗が他の拠点に影響を与えない
他の会社からのソースコード受け入れ時に
対象ソースが何かがわかりやすい

46. いまいちなところ
「あっ！間違えてmasterにpushしちゃいました！」
というミスがたまに発生する
フレームワークの変更の受け入れタイミングを
アプリ開発者が自発的に決められない
（もちろん事前に調整することが前提）

47. ケース３つのまとめ
ケース１ ケース２
運用コスト × △
フレームワーク変更
の取り込む速さ △ ◯
フレームワーク変更
の取り込みタイミン
グを決められる
◯ ×
リリース成果物への
権限設定 ◯ ×
レビューしたものの
み成果物に出来る ◯ ◯
所感 重厚 無難

48. ケース３
• アプリチーム１つ×基盤チーム１つ
• プロジェクトの体制は中〜大規模
• アプリチームは完全にオフショア開発
• 構成管理についてあまり知識がない人ばかり

49. プロジェクト構成
• 画面・バッチ・基盤ごとにモジュールが分かれて
いる
• ブランチ単位でリリース用ソースを分けている

50. ブランチ
• svnと同じdevelopブランチへの直接commit
• masterブランチへのマージは受け入れ時にやる
• 基盤チームはパターン２と同じブランチのフローで開発

51. いいところ
教育・運用コストがかからない
フレームワークの変更をdevelopにmergeするので
素早く変更を反映・取り込むことが出来る
他の会社からのソースコード受け入れ時に
対象ソースが何かがわかりやすい
（契約によっては開発フローを強制出来ないので
相手のやりやすいように開発してもらう）

52. いまいちなところ
「あっ！間違えてmasterにpushしちゃいました！」
というミスがたまに発生する
フレームワークの変更の受け入れタイミングを
アプリ開発者が自発的に決められない
（もちろん事前に調整することが前提）
レビューしていない成果物が
リリース対象に入ってしまう可能性がある

53. ケース３つのまとめ
ケース１ ケース２ ケース３
運用コスト × △ ◯
フレームワーク変更
の取り込む速さ △ ◯ ◯
フレームワーク変更
の取り込みタイミン
グを決められる
◯ × ×
リリース成果物への
権限設定 ◯ × ×
レビューしたものの
み成果物に出来る ◯ ◯ ×
所感 重厚 無難 不安

54. 導入・運用してみて思った事

55. ガイドを用意するとスムーズ
ググったらわかるので皆さん調べてください！
ではなく、ガイド化してあげると受け入れられやす
い
エンジニアならコマンドくらい使えろ！じゃなく
プロジェクトメンバーが使いやすいと思うツールを
選んであげる事が大事
ちなみに、ガイドをGitHubで公開しています
http://syobochim-doc.readthedocs.org/ja/
latest/index.html

56. ややこしいことはさせない
必要最低限な操作しかやらせない
cherry pickやrebaseなどは、
ある程度知見がたまっている、この人なら安心
できるなーと思う人に「こういうことも出来ま
すよ。ただ、こういうところに注意してくださ
い」と個人的に教えてあげる方がいいと思う
よくわかってない人がよくわからないまま何か
すると死ぬ

57. ある程度の柔軟性も必要
今までのやり方と違うので出来ない！生産性が
上がらない！！という人は絶対数いると思う
『こう使うと、こんなメリットがあってね』っ
て説明はしてあげるべきだけど「こうやるん
だ！！」って強制すると「うまくいかない！全
てGitが悪い！！」って思っちゃう人もいて、
自分が疲れちゃうので
「じゃあ、そちらのチームとこちらのチームで
使い方変えましょう」くらいの柔軟性も必要

58. とにかくやってみるとイイ
私はGitをお仕事で使ったことなかったし、GitHub
もブランチ切ったりしたことなかった
でも導入・運用してみたら、辛いこともあったけど
なんとかなった
運用についてのドキュメントや相談相手がチーム外
にでもいると、より安心して運用できると思う
なお、今日お話ししたケース１の事例詳細はドキュ
メントにまとめられてる
https://www.gitbook.com/book/uga/mastering-
builder/details

59. 改善が必要だと思うこと

60. featureブランチは息短めにする
featureブランチが長生きすると、コンフリクト
したり共通部品をうまく使えなかったりと、め
んどうなことが起こりやすくなる
注意喚起はしているけど、実際何週間もfeature
ブランチで開発し続けている人がいるので、解
決策募集中！！
ちなみに「syobochim/XXX」のようなブランチ名
になっていたら息が長くなる兆候なので即刻や
めさせる

61. できれば最初にデモしてあげる
たまに、「えっ？！そんな使い方してたの？！」って
人がいるので、最初に実際の開発フローがイメージで
きるようにデモしてあげればよかったと思う

62. ちゃんとトレーニングを重ねていく
継続して改善していくためには
ちゃんとしたトレーニングが必要
sandboxやhandsonを使って開発者が自由に触
れる環境で遊んでもらうことで
Gitに慣れてもらう＋使い方を知ってもらえ
ればよかった

63. ありがとうございました

64. One more thing…
created by @kawasima
http://unit8.net/gq/