20160128 jjug Nightセミナー_Git実践入門

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

• しょぼちむ • @syobochim • TIS株式会社こんばんわ！

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

※あくまでイメージです

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

開発スタイル

Slide 9

Slide 9 text

構成管理サーバ : GitBucket

Slide 10

Slide 10 text

CI : Jenkins

Slide 11

Slide 11 text

mavenリポジトリ : artifactory

Slide 12

Slide 12 text

ちなみに全部無料！

Slide 13

Slide 13 text

(Redmine以外は) JVMで動く！

Slide 14

Slide 14 text

今日はここの話をします

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

GitBucketのインストールDEMO

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

改善が必要だと思うこと

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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