Git実践入門

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

• しょぼちむ • @syobochim

こんばんわ！

受託開発

お客様は金融系

基盤チームのメンバーとして案件に参入

結論から言うと 少人数チームでGit導入するのはいいけど

大規模でやるためには 本当にちゃんと運用フローを考えて

体制を整えるか ある程度妥協しないと

大惨事になるということ

※あくまでイメージです

今日は私や、私の周りの人が 案件にGitを導入・運用した時の

開発プロセスについて お話ししていきます

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

開発スタイル

構成管理サーバ : GitBucket

CI : Jenkins

mavenリポジトリ : artifactory

ちなみに全部無料！

(Redmine以外は)JVMで動く！

今日はここの話をします

ちなみに全体のざっくりした説明は ↓に書いてます

http://syobochim.hatenablog.com/entry/2015/09/03/214050

GitBucket

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

GitBucketのいいところ

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

GitBucketのインストールDEMO

warを直接起動できる！かんたん！

ちなみに環境構築についての ブログ書きました

http://syobochim.hatenablog.com/entry/2015/05/31/232650

https://github.com/gitbucket/gitbucket/wiki/Backup

極たまにデータが飛ぶことがある バックアップを取得しておくことが大事

困ったこと

GitBucketは無償と思えないほど使いやすい！ 無償＋インストールが簡単なので「とりあえずやってみよう！」の ハードルが低い

ただ、トラブル対応などで 導入・運用のコストはかかってしまうので 可能なら最初から有償ツールを 検討した方がいいかも

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

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

• ケース１ ‣ 小規模で構成管理の大切さを知っている人が各拠点に一人はいる体制

• ケース２ ‣ 小〜中規模でGitを知らない＋構成管理について知らない人たちがほとんどを占める体制

• ケース３ ‣ 中〜大規模でGitを知らない＋構成管理について知らない人たちがほとんどを占める体制

ケース１

• アプリチーム２つ×基盤チーム１つ

• プロジェクトの体制は小規模（１チーム10人未満）

• アプリチームも基盤チームも主体的に行動している • 基盤チームはアプリ開発への影響を理解している • アプリチームは基盤部品の重要度を理解している

• 必要な基盤部品の提供時期がアプリチームの計画とマッチしている

• 構成管理についてある程度のスキルや知識をもっている人が各チームに一人はいる

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

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

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

サイトリポジトリ開発拠点は違うが同じフレームワークを使う場合は

共通用リポジトリから更にリポジトリをforkさせていく

fork

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

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

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

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

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

いいところリポジトリごとにpush権限を変更できるので 「あっ！間違えてpushしちゃいました！」 というミスをシステム的に防ぐことが出来て安全

自分たちがどのチームにいて 何を開発しているのかが明確になる

フレームワーク用にリポジトリを分けているので 自分たちの好きなタイミングでフレームワークの変更を 取り込むことができる

拠点間でのビルドの失敗が他の拠点に影響を与えない

他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい

いまいちなところ

運用コストが高い

フレームワークの変更の取り込みタイミングを 各拠点に任せるので 「後でいいや」って思い続けられると死ぬ

ケース３つのまとめケース１

運用コスト ×

フレームワーク変更の取り込む速さ △

フレームワーク変更の取り込みタイミン

グを決められる◯

リリース成果物への権限設定 ◯

レビューしたもののみ成果物に出来る ◯

所感 重厚

ケース２• アプリチーム複数×基盤チーム１つ

• プロジェクトの体制は小〜中規模

• 構成管理についてあまり知識がない人ばかり

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

プロジェクト構成• リリース用のブランチを作って、そこからリリース成果物を

作成する • 開発者はリポジトリに対して直接pull / pushをする

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

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

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

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

いいところ自分たちがどのチームにいて 何を開発しているのかが明確になる

フレームワークの変更をdevelopにmergeするので 素早く変更を反映・取り込むことが出来る

拠点間でのビルドの失敗が他の拠点に影響を与えない

他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい

いまいちなところ

「あっ！間違えてmasterにpushしちゃいました！」 というミスがたまに発生する

フレームワークの変更の受け入れタイミングを アプリ開発者が自発的に決められない （もちろん事前に調整することが前提）

ケース３つのまとめケース１ ケース２

運用コスト × △

フレームワーク変更の取り込む速さ △ ◯

フレームワーク変更の取り込みタイミン

グを決められる◯ ×

リリース成果物への権限設定 ◯ ×

レビューしたもののみ成果物に出来る ◯ ◯

所感 重厚 無難

ケース３• アプリチーム１つ×基盤チーム１つ

• プロジェクトの体制は中〜大規模

• アプリチームは完全にオフショア開発

• 構成管理についてあまり知識がない人ばかり

プロジェクト構成• 画面・バッチ・基盤ごとにモジュールが分かれている

• ブランチ単位でリリース用ソースを分けている

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

いいところ教育・運用コストがかからない

フレームワークの変更をdevelopにmergeするので 素早く変更を反映・取り込むことが出来る

他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい

（契約によっては開発フローを強制出来ないので 相手のやりやすいように開発してもらう）

いまいちなところ

「あっ！間違えてmasterにpushしちゃいました！」 というミスがたまに発生する

フレームワークの変更の受け入れタイミングを アプリ開発者が自発的に決められない （もちろん事前に調整することが前提）

レビューしていない成果物が リリース対象に入ってしまう可能性がある

ケース３つのまとめケース１ ケース２ ケース３

運用コスト × △ ◯

フレームワーク変更の取り込む速さ △ ◯ ◯

フレームワーク変更の取り込みタイミン

グを決められる◯ × ×

リリース成果物への権限設定 ◯ × ×

レビューしたもののみ成果物に出来る ◯ ◯ ×

所感 重厚 無難 不安

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

ガイドを用意するとスムーズググったらわかるので皆さん調べてください！ ではなく、ガイド化してあげると受け入れられやすい

エンジニアならコマンドくらい使えろ！じゃなく プロジェクトメンバーが使いやすいと思うツールを 選んであげる事が大事

ちなみに、ガイドをGitHubで公開しています

http://syobochim-doc.readthedocs.org/ja/latest/index.html

ややこしいことはさせない

必要最低限な操作しかやらせない

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

よくわかってない人がよくわからないまま何かすると死ぬ

ある程度の柔軟性も必要今までのやり方と違うので出来ない！生産性が上がらない！！という人は絶対数いると思う

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

とにかくやってみるとイイ私はGitをお仕事で使ったことなかったし、GitHubもブランチ切ったりしたことなかった でも導入・運用してみたら、辛いこともあったけど なんとかなった

運用についてのドキュメントや相談相手がチーム外にでもいると、より安心して運用できると思う

なお、今日お話ししたケース１の事例詳細はドキュメントにまとめられてる https://www.gitbook.com/book/uga/mastering-builder/details

改善が必要だと思うこと

featureブランチは息短めにする

featureブランチが長生きすると、コンフリクトしたり共通部品をうまく使えなかったりと、めんどうなことが起こりやすくなる

注意喚起はしているけど、実際何週間もfeatureブランチで開発し続けている人がいるので、解決策募集中！！

ちなみに「syobochim/XXX」のようなブランチ名になっていたら息が長くなる兆候なので即刻やめさせる

できれば最初にデモしてあげる

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

ちゃんとトレーニングを重ねていく

継続して改善していくためには ちゃんとしたトレーニングが必要

sandboxやhandsonを使って開発者が自由に触れる環境で遊んでもらうことで Gitに慣れてもらう＋使い方を知ってもらえればよかった

ありがとうございました

One more thing…

created by @kawasima

http://unit8.net/gq/