Download as PDF, PPTX
20160128 jjug Nightセミナー_Git実践入門
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. GitBucketのいいところ • インストールが簡単 • 無料！ •GitHubに似ているから 普段GitHubを使ってい る人には親しみやすい
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. • ケース１ ‣ 小規模で構成管理の大切さを知っている人 が各拠点に一人はいる体制 •ケース２ ‣ 小〜中規模でGitを知らない＋構成管理につ いて知らない人たちがほとんどを占める体 制 • ケース３ ‣ 中〜大規模でGitを知らない＋構成管理につ いて知らない人たちがほとんどを占める体 制
- 25. ケース１ • アプリチーム２つ×基盤チーム１つ • プロジェクトの体制は小規模（１チーム10人未満） •アプリチームも基盤チームも主体的に行動している • 基盤チームはアプリ開発への影響を理解している • アプリチームは基盤部品の重要度を理解している • 必要な基盤部品の提供時期がアプリチームの計画とマッチして いる • 構成管理についてある程度のスキルや知識をもっている人が各 チームに一人はいる
- 26. プロジェクト構成 • チームや拠点ごとにリポジトリが分かれるようにする • 画面・バッチ・基盤ごとにチームや拠点が分かれている •ベースリポジトリとサイトリポジトリに分けている
- 27. ベースリポジトリ • ライブラリアンのみmerge /pushする権限がある • リリースしてもいいソースのみを格納する
- 28.
- 29.
- 30. ブランチ • 開発者はfeatureブランチを作って開発をする • pullrequest形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
- 31. ブランチ • 開発者はfeatureブランチを作って開発をする • pullrequest形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
- 32. ブランチ • 開発者はfeatureブランチを作って開発をする • pullrequest形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
- 33. ブランチ • 開発者はfeatureブランチを作って開発をする • pullrequest形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
- 34. ブランチ • 開発者はfeatureブランチを作って開発をする • pullrequest形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
- 35.
- 36.
- 37. ケース３つのまとめ ケース１ 運用コスト × フレームワーク変更 の取り込む速さ △ フレームワーク変更 の取り込みタイミン グを決められる ◯ リリース成果物への 権限設定◯ レビューしたものの み成果物に出来る ◯ 所感 重厚
- 38. ケース２ • アプリチーム複数×基盤チーム１つ • プロジェクトの体制は小〜中規模 •構成管理についてあまり知識がない人ばかり
- 39.
- 40.
- 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.
- 46.
- 47. ケース３つのまとめ ケース１ ケース２ 運用コスト ×△ フレームワーク変更 の取り込む速さ △ ◯ フレームワーク変更 の取り込みタイミン グを決められる ◯ × リリース成果物への 権限設定 ◯ × レビューしたものの み成果物に出来る ◯ ◯ 所感 重厚 無難
- 48. ケース３ • アプリチーム１つ×基盤チーム１つ • プロジェクトの体制は中〜大規模 •アプリチームは完全にオフショア開発 • 構成管理についてあまり知識がない人ばかり
- 49.
- 50. ブランチ • svnと同じdevelopブランチへの直接commit • masterブランチへのマージは受け入れ時にやる •基盤チームはパターン２と同じブランチのフローで開発
- 51.
- 52.
- 53. ケース３つのまとめ ケース１ ケース２ ケース３ 運用コスト× △ ◯ フレームワーク変更 の取り込む速さ △ ◯ ◯ フレームワーク変更 の取り込みタイミン グを決められる ◯ × × リリース成果物への 権限設定 ◯ × × レビューしたものの み成果物に出来る ◯ ◯ × 所感 重厚 無難 不安
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64. One more thing… createdby @kawasima http://unit8.net/gq/